A Communication Over Distance Question For the Freaks...

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I was curious what some opinions were on a communications problem that I'm about to have to deal with.

The setup: I need multidrop communications that support star-like and daisy chain at the same time. Distance is on the order 100 feet for the near drops to a max of around 200 yards due to wire/fiber routing. Bit rate can be arbitrarily low - not much to communicate - 300 baud is plenty fast. I need some kind of isolation because the units will be individually powered and separated by such distances. I cannot do wireless of any kind. It has to be wired or fiber.

I do have to worry about collisions and negotiating which node has the floor to send out its information in case more than one ends up with something to send at a given time. And naturally, I'l like things to be as small as possible, low power, and if there was a chip solution that handled all negotiating that would be even better. I'd just throw XPorts at the problem and use network cable except the housing is too tall for my application without using a daughter card. That's possible I suppose.

I kind of like the thought of using fiber because of the inherent isolation / long distance capability but the star configuration thing gets to be a problem as well as the need for a unit in the middle of the string needing to communicate to both directions out. I could do a big loop with fiber I suppose but that adds setup issues - not that big of a consideration since this is a one-time install but I'd prefer to make setup as simple as possible.

Wired adds other issues even though it's easier to make it accept star and daisy chain configurations as well as make adding new nodes trivial.

I was just curious if anyone else had to set anything like this up before and if there were obvious solutions. To be honest, I haven't researched this at all so please don't waste your time researching it for me. I was just curious if anyone had any obvious choices that jumped out at them.

Thanks for any thoughts or help!

Please note - this post may not present all information available on a subject.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I've been looking at some stuff and had a thought about the need for the star/daisy configuration. If I go with the XPort, I can just use a hub or hubs to get the distance and also accomodate a pretty much arbitrary number of nodes. The XPort bumps the price a bit but it makes my job a whole lot easier. I can also use standard net things like UDP to allow other nodes to discover discover a new node and add them in on a list of nodes to talk to. Plus the XPort can handle all collisions and ensuring data gets where it needs to go.

So unless someone has a better idea, I think I'll be going XPort. The powers that be will probably prefer a wiring method they already know and love too.

Please note - this post may not present all information available on a subject.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used RS422/485 in situations like that (max runs around 3000') at 4800 baud. It always left me uneasy when users hooked it up star-wise without a hub, but it always worked. You increase the terminator resistance on each leg. At low baud rates, reflections are not so much of an issue and you can get away with a lot.

The point where you have to start being concerned is when the round-trip pulse travel time (from source to end of leg and back) is a substantial fraction of a bit-time. Shorter, it just looks like "ringing". At 300 baud, this is about 3ms/bit. So, if the round trip is under 300us, there should be little problem. At 1ns/foot (free space,) or about 2ns per foot in cable, this allows for a round trip distance of 150,000 feet! You could have echoes bouncing from every point of the star to every other point of the star and not exceed that.

My personal choice would be to use a master/slave system in which no device talks unless given permission (ie, request from master: "what is your data"). Collisions will have to be handled with some sort of a robust error detection system. It can be at the sender (detecting when it does not hear the same as it sent), then backing off for a retry. In this system, senders back off for a "random" wait so that the two colliding senders don't step on each other in the retry. Or it could be using a CRC and the master requesting a resend. Or, it could be a combination of both or similar.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would be interested to hear about your experience with XPort once you get started, thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because your data rates are so slow, you can get away with “abusing” network topology. Signal reflections due to impedance mismatches and incorrect terminations can be tolerated in a very slow speed environment where the noise and ringing are only a tiny fraction of the data signal time domain. This means you might be able to get away with a so called “illegal” configuration of linear and star topologies all hooked together. You still need a network that can maintain signal levels and can tolerate voltage offset levels over the physical distances you are using.

I can see you have taken bus contention and loading into consideration 8).

Depending on what type of data/connection your star nodes require, you might be able to make dedicated HUB circuit boards. The HUB could be a larger AVR running all the “star” nodes itself, or the HUB could be a multi-processor collection of smaller AVRs using the SPI or TWI as an internal on board multi-processor communications bus. The multi-processor approach would allow you to do things like expand USART capabilities, etc., way beyond what any single AVR can do. Handling the star topologies with a custom HUB design would make selecting the type of the network between the HUBs straight forward.