Module Interconnect cabling standard

It seems to me that we need to decide on a cabling standard for interconnect. I think that everyone is agreed on the use of RS-485. There are a few remaining questions about whether to use half-duplex vs. full-duplex. There also remains the question of the type of cable to use.

SATA:
I originally was pretty happy with the option of using SATA cables, but the pitch and availability of the connectors and the difficulty of obtaining arbitrary lengths of cable, or cables longer than 1m are all serious issues. They also do not allow for running power through the cable.

CAT-5E
CAT-5E was always the backup option I had min ind. It supports up to 350MHz (700Mbps) which is far beyond our requirements. The four pairs allow us to run low current 12V power on the same connector as the RS-485 data. Ethernet transcievers are magnetically coupled, so there's no danger of killing an ethernet card by plugging a RepRap CAT-5E cable into one. The flex resistance at any angle around the cable is close to the same whereas in SATA, there is one preferred flex axis.

All modular 8-pin jacks are locking, whereas only some SATA cables are built that way.

All in all, I think CAT-5E is a better option. The flex isn't as good, and that will be something we have to address, but in all other aspects, I think we win with CAT-5E.

Pinout:
I recommend that we use the same pinout as POE.
1 - White/Green - Master TX+
2 - Green - Master TX-
3 - White/Orange - Master RX+
4 - Blue - +12VDC
5 - White/Blue - +12VDC
6 - Orange - Master RX-
7 - White/Brown - GND
8 - Brown - GND

Power:
POE has a complicated detection protocol, and delivers 48VDC @350mA over CAT-5E for a total of 16.8W. That's not enough to run an extruder and the supply is complicated. I think we should just stick to 12VDC @ 350mA.

The reasoning behind this is that we have a 12V supply, the current is rated based on what the cabling can stand. The on-cable supply is strictly for logic. I don't expect motor drivers or heaters for extruders to run on 12VDC @ 350mA.

Current limiting the 12VDC may be an issue. An optional PMOS switch and a current sensor (resistor + current sense amplifier) on the controller board will be necessary to prevent cable damage. Alternatively a poly-fuse could do the same duty.

Bandwidth:
The most widely available, cheap RS-485 transceivers are 10Mbps transceivers. The max speed for an ATMega running at 20MHz, with doublespeed enabled is 2.5Mbps. Therefore, I think we should populate 10Mbps transceivers, but spec the bus to 1Mbps for now. In the future, as more ARM devices make it into our designs, we can raise the bar.

The additional benefit of high speed is that it provides fast timing. At 1Mbits, we know that the complete transmission time for one byte is 10us. That lets us build a system with close to 10us of latency. 10us in mechanical positioning terms is negligible, which gives us a great advantage in terms of not needing synch lines. We should be able to do synch packets instead.

Duplexing
I've set out the pinout with full duplex transmission in mind (actually, the scheme I'm suggesting is more properly known as dual simplex). There are reasons behind this which I have covered before, but I will add a quick summary so that anyone just tuning in is up to speed.

* We have four pairs. The cost difference in cabling between half duplex and full duplex is negligible.
* Full duplex RS-485 transceivers are widely available for similar price as compared to the half-duplex versions. Both are available in PDIP for reasonable prices.
* In a half-duplex scheme, we have to implement collision detection and arbitration. In a full duplex scheme, we still need to arbitrate access to the bus, but the scheme is far simpler: the master just sends addressed control packets to slaves, which return acks, naks and data. The master can always transmit, which means that synch packets can always go out regardless of whether a slave is returning data or not.

I think this covers most of the cabling standard. Let's see what people think!

Edited 1 time(s). Last edit at 02/04/2009 06:32PM by Annirak.

While the full duplex argument makes sense to me, there has been significant resistance to it. So in an effort to maintain compatibility with other parallel development streams, I will have to set the orange pair to "reserved" and the green pair to tx/rx.

If I run in to timing or bandwidth issues, I will revert my standard to full duplex.

Now that I think about it, I have a feeling that you can do full duplex hardware, but incorporate TX enable on the master, and then join TX+ to RX+, TX- to RX-

However, you know my thoughts on the matter, and standardising the interfacing is a more important community goal than slight advantages of either implementation.
(my vote being half duplex)

Graham