Topic: Community Miner Design Discussion - page 20. (Read 34221 times)

last OT on this.. Our most complex systems have 14 devices talking through the 1 FW cable between the PC and 1st drive. Our vendor says up to 32 can be connected this way (branching out). For main axes the data update rates to/from each drive is 8kHz, and the high-speed galvo drives run with 48kHz update rate. Given that setup the total rate between the host to 1st drive should be update rate(s) x number of drives = a heap o'data.... The smart drives have 32-bit cpu's in them so not sure of packet size but for performance reasons I'd think they are as big as possible (maybe a FW data spec limitation there?)
...
Connectors are "the big ones' vs the mini connectors, cable length from PC to 1st drive is 2meters long, branches from there are very short. This is the only pic I have here at home http://imgur.com/8nKGIUA And yes, I am not thrilled with the connectors but being buried inside a cabinet at least they are not subject to abuse or constant mating cycles.

As for the chipset used.. ya that can be a bugger, not sure chip# but we use cards from SIIG with a TI chip on it. The controls system vendor (Aerotech) Has a very short list of compatible chipsets due to the fanout limitations you mentioned along with other gotcha's. The one time I tried using a mobo FW port (on ASUS Extreme mobo) it worked fine here. Got to Taiwan to install the system and no-go. Timing errors all over the place and had to plug in a spare SIIG FW card they luckily had.

I get your sentiment of "read my OP" and "chill with the scope creep", and certainly I understand the lack of sandwich induced grouchyness.

I've personally used a couple different micros that have more than one I2C bus, not to mention bit banging, software implemented peripherals, etc.  There are many ways to skin a cat, and they aren't always as complex as they seem. That said, do your thing, I'll quiet down in the peanut gallery and observe. 

Anyway, getting back to the original subject which was the Community Miner based on Bitfury chips.

Their industrial scale design posted in a nearby thread has the following pin names on the central controller chip: ICK+ ICK- OCK+ OCK- ITx+ ITx- OTx+ OTx- IRx+ IRx- ORx+ ORx-.

I don't recognize any published standard, beyond the fact that they use differential signaling. punin mentioned UART, but I see explicit clock signal, which means USART or USRT, meaning synchronous and not asynchronous communication.

Is anyone willing to venture a guess about their comm protocol?

Also I was probably a bit grouchy because today is sandwich day but I didn't get the sandwich until about ten minutes ago.

Just some OT
I want a hamburger too

I like that example as  there are a lot of different styles here.

best regards,

 phil

I guess I'm just getting tired of shooting down suggestions that don't make sense in the context of this project, and reminding people why they don't make sense in the context of this project. Maybe I should just leave for a while and come back when y'all are done.

I understand, but this is an international board directed to a global audience.

https://en.wikipedia.org/wiki/Minnesota_nice is not the prevailing dialect of English here.

I guess its time to refresh the "hamburger theory of management".

When an American manager has to discipline a subordinate he will make that scolding will be both prefaced and post scripted by some faint praise.

Very much like hamburger patty is typically delivered between two halves of a bun.

The German manager in the same situation will deliver just the meat patty.

The Japanese manager will only give two bun halves and the Japanese employee is supposed to infer the patty in the middle.

remember internet posting always has a bit of:      


fuck you, you are a moron  


 as it is   built into the typing aspect and the delay of talking.


I am looking at the posts and reading from a different viewpoint then you or sidehack or anyone else posting here.



I find when one wants to really post precisely perfectly what they mean  the posts get too   long   like sloopy's posts tend to do.

 (@ sloopy not an insult I admire you for efforting to write correctly)  

Then they get skipped over or skimmed.   Like this post will be     and some may just see :   fuck you, you are a moron


So many posts seem short and nastly even when they are not meant to be that.


  Note this is a sincere post attempting to  calm the waters on the thread.  No tricky techniques here.

I have a feeling that you are getting upset. I can't understand why? This is just a discussion. I fully support your decision to go with point-to-point USB.

I'm engaging people to explain why other solutions are not competitive for a hobby miner. And some aren't even competitive for an industrial miner. Like daisy-chaining will be a loss no matter how one would implement it.

Maybe because I use "you" more in the sense "y'all" or "youse", a plural "you", not "you" sidehack in particular?

I will not negate your on-the-bench experience with your turnkey solution. Please post how many devices you control and what connectors and cable lengths you are using.

I have broader experience with systems deployed in many office environments. Macintoshes were actually comparatively all right. Some on the motherboard IEEE 1394 controllers (Dell) were so bad that they couldn't reliably handle single 3-meter cable to a single device across the desk and would only work with a 3-feet cable. We had to specify that customers buy a PCI expansion card with particular controller brand (TI? can't recall anymore) to accommodate fairly large office desks from regular office furniture vendors.

The Macintosh deployment I mentioned in my earlier post did partial downgrade to parallel SCSI enclosures and partial upgrade to FibreChannel enclosures. They used Firewire setups only in training where the downtime/slowness wasn't a real obstacle and some trainees actually enjoyed it.

For industrial-scale mining, you want a different project and you want someone other than me to design it because I really don't care one bit about industrial-scale miners. And this project will not use CAN, this project will use USB because specifically-non-industrial miners will probably get along better with it. Also because the point of the framework is to be generic, and I don't really see the use-case for stickminers or pods or a single S1 using CAN instead of USB and those are the use cases I do care about.

Look, it is a desperation solution. I've even seen people routing USB signals through the Neutrik stage audio connectors. (http://www.neutrik.us/) But what's the point.

For industrial-scale mining the multipoint solution will be the best. I'm not a particular advocate of CAN over competitors, but cheap automotive-grade CAN will beat any USB both on price and reliability.

I just want a connector I'm not going to break, which does not include micro or mini. I have to wedge my phone and lay a brick across the cable jack to get it to charge off its shoddy micro connector, which is typical of devices I've seen. I've remounted a lot of mini connectors on stuff because they ripped free of the boards (I'm looking at you, New R-Box) but rarely because the jack broke. And after a couple years of refurb I never saw a busted B jack.

1 Firewire cable from the PC feeds first drive, that drive and all other drives is also a repeater (hub) with extra 2 ports. Each port from that drive feeds 2 more drives which also have 2 extra ports, those feed 2x more drives, rinse and repeat. Think of a tree, first FW cable from the PC is the trunk which branches out at each drive and the branches have branches. Any other name for that branching config?

Also if it connector durability really becomes an issue one can always use industrial grade high-retention force USB sockets. Exceeding reliable but also cost around 5x what you can get normal USB sockets for...

"daisy-chained star config?" What is that? Iron butter? Daisy-chained and star(hub & spoke more generally) are polar opposites.

Not sure what you are trying to say here.

Also, what kind of Firewire connectors are you using?

You won't be able to get I2C to work reliably from one PCB to another PCB. Technically its a complete loss.

SMBus is very similar to I2C and if used on expansion board it is routed through a separate pair of twisted wieres, e.g. Wake-on-LAN.

Just for the sake of posting it here.

Here's what sidehack et al have laid out

https://bitcointalksearch.org/topic/m.13932487

Here are Firewire stats from one of our systems that has been running 24x7 for the past 3 weeks. It has 14 axes of motion with the motor drives fed via Firewire in a daisy-chained star config. 1 main feed to 1st driver, branching out to 2 more drives, branching out to two more, etc.
https://imgur.com/kvWcSM1

Perfect with zero errors. Then again, they are fed by the motion systems RTOS which WIndoze rides on top of...