off the shelf RS485 network card

RS485 (aka EIAA-485) is specified for up to 32 drivers and 32 receivers per network.

You need a dual contrarotating ring network, rather like FDDI in terms of topology. Sounds rather fun to specify and design! I would be pleasantly surprised if there is anything COTS that does the job.

--------------------------------------- Posted through

Network cards implies a bus or backplane. Are you using one or should these be stand-alone modules?

The RS-485 standard only allows up to 32 drops, IIRC, and doesn't do particularly well in a ring configuration.

--
Rich Webb     Norfolk, VA

Most buses have trouble in a ring configuration if you are pushing the speed/distance barriers, but will work fine if your demands are light. For example, RS-485 is ideally wired as a bus with resistor terminators at each end. But for slow rates and short distances, it should work fine to connect everything as a ring and have the terminators pretty much anywhere (including as larger resistors at each node).

I believe you can get 1/8th load RS-485 drivers, which will then allow

256 devices on a bus.

A simple ring like this would work and be redundant in the case of a breakage, but it would not tell you where the break had occurred (or even /if/ a break had occurred. You could find out about breaks by intentionally breaking at another point, and testing how far you can communicate in each direction.

Some RS-485 drivers will work reasonably well even if there is a break on one of the lines.

There are also CAN drivers that can handle redundant or faulty conditions, that might be of interest.

Good comments on the ring topology. WRT CAN, yes I'd certainly second the suggestion to the OP to take a look at it. A large number of nodes and relatively slow data rate sounds like a sensor & control network where CAN's small packet size would be a good fit (not to mention the built-in error checking, retransmission, prioritization, etc.).

--
Rich Webb     Norfolk, VA

Your wording implies a *physical* set of point-to-point links. This can be accomplished "literally" in that same sense. E.g., much like FDDI.

Does a powered down/defective node count as a "break"? I.e., can you count on all nodes being "up" at any given time (two or more being OFF would be an irrecoverable failure)

For example, a pair of RS232 links -- one clockwise and one counterclockwise -- from each node to its two adjacent neighbors gives you the physical capabilities you seek (though it forces each node to participate actively in every message exchange).

You can also implement a Token Ring network (e.g., ArcNet) in which a "communications device" handles much of the overhead of moving messages around (years ago, there were

8051-ish solutions with ArcNet controllers).

If you have any need for synchronization between nodes (e.g., shared timebase), then the easier implementation is a bus-oriented one. (Note that the physical topology can

*force* a ring's "problems" onto a bus topology) This allows all nodes to see the same data/event COINCIDENTLY.

If you need the ring to bretain some integrity in the face of a break, then you need at least two physical connections per node. Note that you need not have both connections *active* at all times. Rather, you just need to be able to sense your "current" connection is defective and "recover" by switching to your "backup" connection. (of course, your protocol must be smart enough that the controls don't start oscillating) The relative cost of the hardware to do so must be weighed against recovery time, protocol complexity, etc.

Have you considered a wireless solution? (you've not explained the physical size of the ring but ~250 would probably NOT all be colocated in a 1 meter segment! :> ) ZigBee is an attractive, low power solution in your stated bandwidth. (you can chose to implement a ring protocol, bus protocol, mesh, etc.)

e

I think the winsystems Zigbee bd. uses the Xbee-pro. It has indoor/ urban range listed as 100m.

What interface/connection does the OP's controllers have (usb or PCI or PC104 or ??) or is he building an SBC?

We did that a long time ago and put a relay on one of the RS-232 modem control outputs. If that wasn't powered, the relay bypassed the node (can't really take credit for the idea, we were inspired by Token- Ring, which does something very similar). Also, you don't really need pairs of RS-232 links, just a funky cable to connect TX from one node to the RX of the next node. A second ring would present opportunities for redundancy.

ARCNet is actually token bus, not token ring. It uses a broadcast medium with repeaters/hubs. It manages *access* by bouncing a token around the network to all the nodes in sequence, only the holder of the token can transmit, but those transmissions are broadcasts. Contrast that to a token ring (like 802.5 Token Ring, or FDDI), which physically transmits messages around a ring of point-to-point links, with one of those messages being the token that allows transmission. A token ring actually allows several messages to be circulating on the ring at once (presuming the bandwidth-delay product of the physical ring is high enough, of course), which is not possible with a token bus. A token ring also has certain electrical advantages from being composed of point-to-point links.

e

Sorry, I guess I didn't ask my question very well. The distance between nodes can be several kilometers or just one or two meters. We can use fibre for the larger distances. The network cards need to be standalone with a connection to the host preferably RS232 but maybe whatever's available. The topology is not a bus but more of a daisy chain. We were thinking of a scheme where messages propagate in both directions around the ring, to get the redundancy. All nodes are powered up all of the time except when there's a fault/ power fail.

Ouch! "Important detail", that. :-/

You've indicated performance criteria. What about cost, size and reliability?

Without really knowing your application, I would look into a pair of RS232 interfaces -- one counterclockwise, the other clockwise -- with an external "media adapter module" that you "select at deployment".

E.g., if B's clockwise neighbor (C) is a meter away, then B's "clockwise media adapter module" is populated with something like an EIA232 translator (perhaps even less depending on other electrical characteristics). The same applies to *C's* "COUNTERclockwise media adapter module". Similarly, if B's counterclockwise neighbor (A) is a *mile* away, you could populate B's "counterclockwise media adapter module" with something like an RS232-fiber module (long haul modem) as well as A's "CLOCKwise media adapter module".

[hopefully I've been consistent in my clockwise and counterclockwise terms in that example :> if not, hopefully you can figure out what I mean with the help of a little sketch with two interfaces on each node]

This puts each node *in* the message loop physically and procedurally. I.e., the message has to pass *through* each node and be handled by the processor, there.

If you have the budget, add a small MCU for each node that simply does all of the communications protocol. E.g., something with two UARTs and an SPI interface (which talks to the "main CPU"). Since you can "nail down" your protocol, you can test and debug that code and "fix" it into that "communications processor".

Hint: since you are going to *process* packets (messages) circulating around the ring, you can modify your protocol so that you *tag* each packet with the "ring sequential" ID of its sender (which might be different from it's

*logical* ID). In that way, a node can "know" that it is "node X" and, if it can't talk to "node Y" on it's clockwise link but *can* talk to Y-1, it can deduce that there is a break between Y and Y-1 (since Y and Y-1 "must" be "ring adjacent"). [look at the RUPI for some historical context]

You can still look at wireless options but long distance radio modems get pricey (OTOH, stringing a km of fiber isn't cheap!)

Also, the synchronization issue gets trickier given this mix of different interconnect technologies (assuming synchronous operation *might* be required above syntonous requirements)

Google "Rs-485 HUB"

Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller? If you are using point to point, you do not have to even control the enable signal.

If you are running for long distance, then you might consider using a more advanced bit encoding like Manchester coding.

BR Ulf Samuelsson

Mixed mode IC designs that include both a microcontroller and something like robust differential analog transceivers like RS-485, RS-422, RS-232, CAN, etc. tend to be pretty tricky (and expensive).

I've never seen an off-the-shelf microcontroller with RS-485, RS-422, or RS-485 tranceivers, and I've never met anybody with enough cash to design one and have it fabbed.

--
Grant

While I can understand that there are no standard compliant RS-232 integrated controllers due to the large +/-6 V voltage swing and the large power dissipation in the fault cases, RS-422/485/CAN will operate from +5 V.

However, the OP was talking about distances up to 1 km and speeds up to 250 kbit/s, which is twice what the standard suggest (in distance or speed). At such distances the lame +12/-7 V RS-485 common mode voltage range is not enough, so anyway, you would have to use optoisolators for galvanic isolation.

Maybe I wasn't too clear. Instead of adding a board with RS-232 bridge to RS-485/422, he should consider adding an RS-485/422 transceiver to the Microcontroller board.

Best Regards Ulf Samuelsson

I thought maybe you were hinting about a new AVR part soon to be announced. :)

--
Grant