Poll: My Project's Network Requires?

Projects Networking, Protocols, and Devices
1

I'm curious as to the types of network topologies and features for which people perceive a need. I frequently see people say, "mesh", when in fact they really mean star or even less frequently a tree topology. There are some subtle yet important differences and distinctions. I'm blurring the lines between some of the topologies above because if you have a multi-hop star, you basically have a tree. Likewise, if you have a tree, you have a multi-hop star.

Here is a nice wikipedia article on network topology. I purposely gloss over some. I can see a chain as a viable option but given their failure scenarios, they are frequently passed over for more reliable topologies. As such, topologies such as chain, I'm ignoring. Likewise, rings can be fragile but have at least one redundant link, making them far more palpable than basic chains.

Of course, I'm also interested in your routing needs, in so far as dynamic vs static; or no routing at all.

I'm also interested in the perceived need for lossy (example, IP/UDP) or reliable, best effort (example, IP/TCP) transport. Is ordered delivery important? Also like to hear about the need for unicast, broadcasting, and multicasting.

Lastly, I know the xbees are very popular and would be interested to hear if any of you have leveraged even a fraction of their dynamic routing and mesh networking capabilities, and if so, to what scale. I frequently read about these guys being used as simple point to point links.

I'm not trying to create a network primer here, but being able to clearly define your requirements is usually the first step in creating a solution. Along these lines, in my own experience, most people have no idea of the different types, and associated advantages and disadvantages of each. And its made all the more confusing in that the wrong terminology is frequently used. I've tried to provide some educational references but if some of the distinctions I'm making are not clear to you (or too much reading), please feel free to ask. Networking can be extremely complex so don't be embarrassed about asking.

2

How about adding a "bus" option.

My personal preference (in an RS-485 low speed control network) is for all of the above, well maybe some of the above.

Basically I use a bus, but I'm not shy to have long stubs, so I guess that's a star. Also I like the idea of bringing the cable back to the source to make a sort of ring (actually a circular bus I suppose) as this allows the cable to be cut once with no loss of functionality.

Years ago I designed a ring bus for a building control system. It used HDLC protocol on optical fibers and had two rings running in opposite directions IIRC. That was very reliable.

Rob

3

Graynomad:
How about adding a "bus" option.

I specifically didn't add bus because not doing so was self serving. I'm specifically interested in the RF angle though in hind sight, I don't guess I specified that. Once you're dealing with RF, bus doesn't really apply because other topologies typically, naturally fall out. Given that you requested it, and it may well serve others, I honestly don't see a reason to exclude.

Along these lines I was surprised to read the I2C can also be used in star/hub topologies. IIRC, I read here someone used that for home automation/sensor network.

Does this mean your projects tend to be of of scada/industrial type? Is SDLC/HDLC your preferred protocol? Are there SDLC/HDLC arduino/AVR stacks?

4

i2c is just a multi-drop network at (often) slow speeds so I would think you could do what you like topology wise.

Does this mean your projects tend to be of of scada/industrial type?

Yep.

Is SDLC/HDLC your preferred protocol?

Not these days. I'm working on a simple async serial protocol. Multi-drop, multi-master, slow speed so should be topology agnostic.

Are there SDLC/HDLC arduino/AVR stacks?

I wouldn't expect so but haven't looked. I know CAN uses a similar bit-stuffing arrangement and there are CAN-equipped AVRs, but I haven't looked to deeply into the protocol details.

Rob