Maker Pro
Maker Pro

coax Ethernet

Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.

However, we'd like to switch to Ethernet for robustness and for better
realization of an ideal "single master, multiple sensors" model.

Using RS485, we often use a "wet Y" or "wet W" to split the RS485 lines
into 2 or 3 paths that are connected to sensors a short distance from
the junction (~1 m or so). I want to figure out how to implement this
same functionality with Ethernet (either coax or twisted pair).

We have our cables custom-made. They are armored and quite robust.
I'd like to avoid putting any electronics inside the Y or W junction.

For twisted pair, I've heard that you should not unravel the pair more
than an inch or you'll severely compromise the data integrity.

I'm hoping that perhaps the old coax approach to Ethernet might be a
reasonable solution since everything was tied together in an analog
fashion with BNC connectors. However, it a daisy-chain configuration
rather than a star configuration, which is really what I'm hoping to
achieve (perhaps with clever impedance matching techniques?).

Am I barking up the wrong tree? If I search hard enough am I likely to
find a solution, or am I just headed in the wrong direction? Are there
any Ethernet tutorials that you've found helpful at a hardware level?
Ultimately, I'm going to have to put the whole thing together myself,
from hardware TCP/IP stack to MAC to PHY, so I'm also interested in
recommendations for hardware solutions (I'm hoping for at least 5 Mbps
throughput).

Thanks in advance for the help.
Todd
 
R

Rene Tschaggelar

Jan 1, 1970
0
Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.
[snip]

Todd,
leaving the end-end terminated transmission line for a T-tapped
structure is a matter of impedance matching/mismatching.
Whether twisted pair RS485 or ethernet or twisted pair
ethernet doesn't really matter.

I remember the TI RS485 transceivers adapted for long and fast
transmissions. The 65HVD23D achieves [email protected] and the
65HVD24D achieves [email protected]

Rene
 
R

Richard Crowley

Jan 1, 1970
0
tschoepflin wrote ...
I'm hoping that perhaps the old coax approach to Ethernet might be a
reasonable solution since everything was tied together in an analog
fashion with BNC connectors. However, it a daisy-chain configuration
rather than a star configuration, which is really what I'm hoping to
achieve (perhaps with clever impedance matching techniques?).

Perhaps we forget that Ethernet was wired with coax
(huge RG-8 stuff the size of your thumb, and then RG-
58, etc.) long before UTP ("Cat5", etc.) ever came along.
HOWEVER, it was only defined as daisy-chain, never
as any other topology. For many reasons, impedance
being only one.

You didn't mention what your data rates are here?
If they are low enough you could get away with the
same kind of CSMA/CD (carrier-sense, multiple-
access/collision-detect) scheme that Ethernet uses,
but designed to contend with the kind of reflections,
etc. you would get from a random tree of coax.

If you could live with lower throughput, and could
design your own transcievers, you could get away
with coax joined any old way you wish, because the
transcievers would make allowances for the lousy
transmission medium. But I don't think you would
be successfull trying to use stock Ethernet interface
nodes with a random coax tree. Unless maybe
your the time between packets was MUCH longer
than the packets themselves.
 
Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.

However, we'd like to switch to Ethernet for robustness and for better
realization of an ideal "single master, multiple sensors" model.

Using RS485, we often use a "wet Y" or "wet W" to split the RS485 lines
into 2 or 3 paths that are connected to sensors a short distance from
the junction (~1 m or so). I want to figure out how to implement this
same functionality with Ethernet (either coax or twisted pair).

We have our cables custom-made. They are armored and quite robust.
I'd like to avoid putting any electronics inside the Y or W junction.

For twisted pair, I've heard that you should not unravel the pair more
than an inch or you'll severely compromise the data integrity.

I'm hoping that perhaps the old coax approach to Ethernet might be a
reasonable solution since everything was tied together in an analog
fashion with BNC connectors. However, it a daisy-chain configuration
rather than a star configuration, which is really what I'm hoping to
achieve (perhaps with clever impedance matching techniques?).

Am I barking up the wrong tree? If I search hard enough am I likely to
find a solution, or am I just headed in the wrong direction? Are there
any Ethernet tutorials that you've found helpful at a hardware level?
Ultimately, I'm going to have to put the whole thing together myself,
from hardware TCP/IP stack to MAC to PHY, so I'm also interested in
recommendations for hardware solutions (I'm hoping for at least 5 Mbps
throughput).

The original Ethernet was not a daisy chain, but a broadcast medium.
The coaxial cable was supposed to be ternminated at either end, and
every transceiver transmitted to every receiver on that length of coax.

Obviously, you can use it as a star system

The two crucial points about Ethernet were

1) Collision detection

2) Random back-off after a collision was detected.

Collision detection just meant that a receiver monitored its own
transmitters output, and signalled a collision whenever the received
signal didn't match the transmitted signal, which immediately killed
the transmission.

Random backoff meant that the station didn't try to re-transmit
immediately, but waited for variable amount of time before attempting
to retransmit.

The theory behind this is pretty well understood an works time, but you
don't want to load an Ehternet link at anything approaching its maximum
capacity - IIRR around 10% is as high as you'd want to go.

That is about 1Mbit/sec on the original 10Mbit/sec hard ware, but that
covered distances of over a kilometre. Waht the 100Mbit/sec hard ware
looks like I've no idea.

The single coaxial cable can be extended as an un-rooted tree by simple
dumb repeaters - bearing in mind that the area that can be covered by
an Ethernet is limited by propagation delay and attenuation - or by
more complicated bridges that store and forward packets addressed to
stations outside a particular net, or packets from outside the net
addressed to stations within a particular net.

Either mode of extension allows you to realsie the physical connections
as a start system, though it does make the system a little more
expensive.

It was quite a powerful system, and remarkably simple.

The is a lot of stuff about it on the web

http://www.livinginternet.com/i/iw_ethernet.htm
 
R

Rene Tschaggelar

Jan 1, 1970
0
Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.
[snip]

The original Ethernet was not a daisy chain, but a broadcast medium.
The coaxial cable was supposed to be ternminated at either end, and
every transceiver transmitted to every receiver on that length of coax.

Obviously, you can use it as a star system

The two crucial points about Ethernet were

1) Collision detection

2) Random back-off after a collision was detected.
[snip]


Bill,
the poster is talking about a master-slave
communication system. This means there are
no collisions.

Rene
 
Rene said:
Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.
[snip]

The original Ethernet was not a daisy chain, but a broadcast medium.
The coaxial cable was supposed to be ternminated at either end, and
every transceiver transmitted to every receiver on that length of coax.

Obviously, you can use it as a star system

The two crucial points about Ethernet were

1) Collision detection

2) Random back-off after a collision was detected.
[snip]


Bill,
the poster is talking about a master-slave
communication system. This means there are
no collisions.

Perfectly true, but he needs to understand that the classical Ehternet
was not a daisy-chained system, which means that he need some
understanding of how it worked and why the protocol worked the way it
did.

If you broadcast Ethernet packets ontp the cable from the master
station, and only let the addressed station respond, you certainly
don't need collision avoidance, but the size and structure of the
minimum Ethernet package is determined by the collision dection system,
and if he wants to use standard Ehtenet hardware an software as the
basis of his system he is constrained by these rules.
 
Hi all
I'm trying to solve a major problem ... <RS-485 sensors> communicate with the
surface unit at distances well over 100 m
However, we'd like to switch to Ethernet
Using RS485, we often use a "wet Y" or "wet W" to split the RS485 lines
into 2 or 3 paths that are connected to sensors a short distance from
the junction (~1 m or so). I want to figure out how to implement this
same functionality with Ethernet (either coax or twisted pair).

The trickiest Ethernet wiring relates to gigahertz and 100baseT
systems; if you
can tolerate 10baseT (10 MHz Ethernet) you won't have that kind of
problem
at all. For 100m distance, you could use either thinnet (10base2) or
unshielded
twisted pair (10baseT) wiring without particular problems, BUT I'm not
sure the
exact wire specs for commercial buildings (cat-5) are gonna work for
a ruggedized application like yours.

If the wet wiring can carry two pairs with 110 ohm impedance and
suitably low
crosstalk, 10 MHz Ethernet will work fine. It might even tolerate
your RS-485
wiring. And there were baluns used with 10base2 that allowed
single-pair
transmission (this is NOT recommended, and it makes full-duplex
impossible,
but... it's a thought). Distance limits and specific losses in the
wiring are unlikely
to be critical at 100m.
 
J

Joerg

Jan 1, 1970
0
Hello Todd,

I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.

However, we'd like to switch to Ethernet for robustness and for better
realization of an ideal "single master, multiple sensors" model.

Using RS485, we often use a "wet Y" or "wet W" to split the RS485 lines
into 2 or 3 paths that are connected to sensors a short distance from
the junction (~1 m or so). I want to figure out how to implement this
same functionality with Ethernet (either coax or twisted pair).

We have our cables custom-made. They are armored and quite robust.
I'd like to avoid putting any electronics inside the Y or W junction.

For twisted pair, I've heard that you should not unravel the pair more
than an inch or you'll severely compromise the data integrity.

I'm hoping that perhaps the old coax approach to Ethernet might be a
reasonable solution since everything was tied together in an analog
fashion with BNC connectors. However, it a daisy-chain configuration
rather than a star configuration, which is really what I'm hoping to
achieve (perhaps with clever impedance matching techniques?).

Am I barking up the wrong tree? If I search hard enough am I likely to
find a solution, or am I just headed in the wrong direction? Are there
any Ethernet tutorials that you've found helpful at a hardware level?
Ultimately, I'm going to have to put the whole thing together myself,
from hardware TCP/IP stack to MAC to PHY, so I'm also interested in
recommendations for hardware solutions (I'm hoping for at least 5 Mbps
throughput).

AFAIK neither coax not twisted-pair LAN are suitable for application
where you want to just "tie together" cable branches at arbitrary
points. Depending on what you mean by "multiple" maybe you could
consider dropping down one pair per sensor.

Anything else would be more of a custom solution. Can be done though if
the cables are terminated properly at all end points.
 
The trickiest Ethernet wiring relates to gigahertz and 100baseT
systems; if you
can tolerate 10baseT (10 MHz Ethernet) you won't have that kind of
problem
at all. For 100m distance, you could use either thinnet (10base2) or
unshielded
twisted pair (10baseT) wiring without particular problems, BUT I'm not
sure the
exact wire specs for commercial buildings (cat-5) are gonna work for
a ruggedized application like yours.

If the wet wiring can carry two pairs with 110 ohm impedance and
suitably low
crosstalk, 10 MHz Ethernet will work fine. It might even tolerate
your RS-485
wiring. And there were baluns used with 10base2 that allowed
single-pair
transmission (this is NOT recommended, and it makes full-duplex
impossible, but... it's a thought).

Since the classic original 1981 Ethernet was half-duplex anyway, and
probably perfectly adequate for this application, the
non-recommendation needn't be taken too seriously.

http://www.answers.com/topic/ethernet
Distance limits and specific losses in the wiring are unlikely
to be critical at 100m.

Though this does depend on the speed you want and the protocol you end
up using to get it.
 
P

Paul Hovnanian P.E.

Jan 1, 1970
0
Hi all
I'm trying to solve a major problem we have at work. We have a master
unit on the surface and multiple sensors in the water. For the past 10
years they have been networked by RS485 operating at 1.5 Mbps. Our
production people have gotten the sensors to communicate with the
surface unit at distances well over 100 m with clever impedance
matching tricks.

However, we'd like to switch to Ethernet for robustness and for better
realization of an ideal "single master, multiple sensors" model.

Ethernet is not a 'single master' protocol, its peer-to-peer with all
the collision detection and other overhead that this entails.
Using RS485, we often use a "wet Y" or "wet W" to split the RS485 lines
into 2 or 3 paths that are connected to sensors a short distance from
the junction (~1 m or so). I want to figure out how to implement this
same functionality with Ethernet (either coax or twisted pair).

We have our cables custom-made. They are armored and quite robust.
I'd like to avoid putting any electronics inside the Y or W junction.

For twisted pair, I've heard that you should not unravel the pair more
than an inch or you'll severely compromise the data integrity.

I'm hoping that perhaps the old coax approach to Ethernet might be a
reasonable solution since everything was tied together in an analog
fashion with BNC connectors. However, it a daisy-chain configuration
rather than a star configuration, which is really what I'm hoping to
achieve (perhaps with clever impedance matching techniques?).

Its not a daisy chain, its a single bus with impedance matching
terminations on each end.
Am I barking up the wrong tree? If I search hard enough am I likely to
find a solution, or am I just headed in the wrong direction? Are there
any Ethernet tutorials that you've found helpful at a hardware level?
Ultimately, I'm going to have to put the whole thing together myself,
from hardware TCP/IP stack to MAC to PHY, so I'm also interested in
recommendations for hardware solutions (I'm hoping for at least 5 Mbps
throughput).

The classic coax ethernet was good for a theoretical 10 Mbps, but 5 Mbps
might be an optimistic upper limit, depending on the number of hosts,
packet size, protocol overheads, etc.
 
S

Sjouke Burry

Jan 1, 1970
0
Paul said:
Ethernet is not a 'single master' protocol, its peer-to-peer with all
the collision detection and other overhead that this entails.
I have worked with coax Ethernet a lot in the recent
past. I even have a small 3 computer dos/win311 network
in my home.
The big problem with the coax is, that it has a maximum
length of 75 meters(~80 yards). On one such line, you can
connect several computers,by cutting the line and putting
in a BNC T connector.
At our institute we had concentrator units for 16 cables
in each corridor,which were then connected to ~ 1 inch
thick high speed network cable with a high impedance
T connection. One high speed cable serviced several
concentrators.
So your 100 m branches would not work well with coax
Ethernet, unless you could bring those concentrators
very close to a set of drop down lines.
If I would be intrumenting this, I would use twisted pairs
in the sensor cables,you need 2 twisted pairs in each
one,and connect them to rather cheap router units,
4 to 16 to a unit.
Then connect those to a master unit.
You would need a smart micro down at the end of the
cable, to interface.
If you use your data collecting computer as master,
requesting data from each sensor package in succession,
there will be no problem with data collision,and data
traffic can get as high as ~800.000 bytes per second,
the other 200.000 being needed for the downward
traffic.
I really got that speed on dedicated 10Mbit Ethernet,
with two computers exchanging packets in handshake
mode.
 
Top