RJ45/8P8C alternatives

On 2014-11-30, Don Y <this@is.not.me.com> wrote:
> Hi,
>
> I have an irregular-shaped (metal) enclosure to which an ethernet connection
> must be mated.
>
> I can afford to run at 10BaseT speeds -- though would REALLY REALLY prefer
> 100BaseTX (-T2 is not a practical option).
>

They sell M8 to RJ45 cables wired for ethernet (10 or 100), so if you go that
route you won't be pioneering it.

-- 
umop apisdn

On Thu, 04 Dec 2014 18:13:04 -0600, Joe Chisolm <jchisolm6@earthlink.net>
wrote:

>On Thu, 04 Dec 2014 16:10:52 -0800, josephkk wrote:
>
>> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
>> <jchisolm6@earthlink.net> wrote:
>>=20
>>=20
>>>> So, *through* the edge connector is your "least controlled" point of
>>>> transmission?  I.e., you still try to maintain signal integrity on
>>>> either side of that connection -- you're not *casually* treating the
>>>> signals past the connector(s)?
>>>
>>>That's true.  The layout guy ran diff pairs between the connectors.  =
I'm
>>>not sure about careful impedance control, I'd have to go back and look
>>>at the stackup to see exactly what he did.  My point was there is a =
mobo
>>>RJ45 connector -> small patch cable -> backplane RJ45 -> edge =
connector
>>>-> card->lan mux->phy and everything works fine.
>>=20
>>>Some day I'd like to take
>>>some cat5, re-twist to maybe every foot and test.
>>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>=20
>>>I could fix the FW on
>>>the embedded system to force 100M or 10M and see what happens.
>>=20
>> Wow, that would be a significant twist reduction from the original
>> cable.
>>=20
>> ?-)
>
>I figure if you are going to break it, go all out....
>For short runs, say under 10ft, wonder what you can get away with.
>I would never put it in a product like that but would be fun
>to try anyway.

In all fairness, Cat3 is good for 10 MHz and has about 1 to 2.2 turns per
foot (3.3 to 7 turns per meter).  The biggest issue that i am finding is
that the blips in line impedance are a lot more disruptive.

?-)
=20

On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
<jchisolm6@earthlink.net> wrote:

>Try it.  Take a patch cable, whack it in half and solder a DB9M and F in
>line.  Run several GB of TCP traffic through it and watch the error
>counts.  If you have access to the FW you could pull out more detail on
>what lower level errors you are seeing.

The easy way to test that is to find a 10/100baseT *MANAGED* ethernet
switch, and use an SNMP MIB browser to look at the errors at the MAC
(Data Link) layer.  There are plenty of SNMP tools available to do
this.  Details, if anyone wants me to scribble something on the topic.

I used to do this for testing some rather marginal communications
links.  For example, running 10 or 100baseT over greater than 100
meter cable runs.  My favorite demo is to put connectors on both ends
of a 1000ft roll of CAT5e or CAT6, and see if it works.  1000ft of
10baseT is easy, but 100baseT has NEXT (near end cross talk) problems.

I've never tried a DE9P/S connector pair for ethernet.  However, I
have run 10baseT through the common 0.093 Molex nylon "power"
connectors with good results.  The mechanical designer forgot to
install an RJ45 jack on the case and wanted to use four spare pins on
the power connector for ethernet.  I found no problems with any
"impedance bump" at either 10 or 100baseT.  I also ran a BER (bit
error rate) test over a cable with two such connectors inline, and
found something like 5 errors after a 2 day run.  However, a Fluke
cable certified failed the cable, which may be a problem.  My
guess(tm) is that a DE9P/S connector pair will work.

Google Images for "military rj45". 
<https://www.google.com/search?q=military+rj45&tbm=isch>
<https://www.google.com/search?q=Amphenol+LTW+rj45&tbm=isch>

M12 to RJ45 ethernet adapter:
<https://www.amphenol.com/about/news_archive/2012/104/>
Note that it has only 4 pins.  More:
<http://www.farnell.com/datasheets/1672292.pdf>



-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On Wed, 03 Dec 2014 23:31:47 -0700, Don Y <this@is.not.me.com> wrote:

>As I said:
>   "Connection must be weather-resistant (sheltered location; not "indoor").
>I avoided claiming "weather-PROOF".  The locations will be sheltered and
>*generally* protected from the elements (direct sun, direct precip, direct
>wind).

>However, no protection from temperature extremes, humidity, indirect
>sun/wind/precip, etc. (hence my "not 'indoor'" claim)

Kinda sounds like the specs for the RJ11 connector used inside telco
MPOE (minimum point of entry) boxes:
<https://wiki.sonic.net/wiki/MPOE_Types>
The RJ11 connector works nicely outdoors, but does require some
silicon grease to reduce oxidation.  If it works for Ma Bell, it
should work for your gizmo.

For panel mount, something like this perhaps?
<http://www.newark.com/amphenol-ltw/rjs-5epffj-sc7008/connector-rj45-rcpt-8pos-panel/dp/48W0838>

>There is no *need* to stick to the RJ45 form factor.  I think that severely
>limits the choices and complicates the fitting of the connector to the
>enclosure.

There may not be any need, but the almost endless variety of mounting
and protection configurations make the RJ45 connector a good choice.
Put differently, why would you *NOT* want to use an RJ45 for ethernet?
There has to be a very good reason to justify something different from
the common ethernet connector standard.

>E.g., why are there mini-USB connectors instead of forcing ALL such connections
>to adopt the standard A/B connectors?  (Ans:  because the mini connectors can
>be deployed in locations that the standard ones can't!)

I think you mean MicroUSB.  MiniUSB had problems.  Small connectors
are a basic requirement on cell phones and portable devices.  You
apparently don't have that requirement.

>But, if that requirement complicates the connector choice, I can move the
>power off the connector and handle it in other ways (power is relatively easy
>and tolerant of a wide variety of connection methodologies)

Speaking of power, I don't mind dealing with PoE (802.11af) at 48VDC
because the source is properly protected from shorts and backfeeding
power.  I do mind home made kludges, where someone uses the extra 4
wires in the CAT5e cable for power.  The resistance of the cable is
usually high enough to prevent a fuse from blowing.  I've seen a few
minor meldowns.  If you're going to do your own PoE thing, please
design in some protection.

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On 12/5/2014 10:33 AM, Jeff Liebermann wrote:
> On Wed, 03 Dec 2014 23:31:47 -0700, Don Y <this@is.not.me.com> wrote:
>
>> As I said:
>>    "Connection must be weather-resistant (sheltered location; not "indoor").
>> I avoided claiming "weather-PROOF".  The locations will be sheltered and
>> *generally* protected from the elements (direct sun, direct precip, direct
>> wind).
>
>> However, no protection from temperature extremes, humidity, indirect
>> sun/wind/precip, etc. (hence my "not 'indoor'" claim)
>
> Kinda sounds like the specs for the RJ11 connector used inside telco
> MPOE (minimum point of entry) boxes:
> <https://wiki.sonic.net/wiki/MPOE_Types>
> The RJ11 connector works nicely outdoors, but does require some
> silicon grease to reduce oxidation.  If it works for Ma Bell, it
> should work for your gizmo.

The NID (Network Interface Device) tends to see very little physical access.
I suspect ours has been "opened" three times in 20+ years:  once when
installed, once when we had some line problems and once when I changed the
feeds into the house.

Imagine having that RJ11 on the back porch and carrying your (wired) phone
out there from time to time.  Granted, it may only see one use per week.
But, a helluva lot more than 3 per score years.

[Our back porch RJ11's are behind waterproof covers.  Even keeps the critters
from turning them into egg caches, etc.]

> For panel mount, something like this perhaps?
> <http://www.newark.com/amphenol-ltw/rjs-5epffj-sc7008/connector-rj45-rcpt-8pos-panel/dp/48W0838>

That's really pretty large (a consequence of RJ45!).  Looks like I'd need to
find a clear area at least 3/4" - 1" dia.  Plus, a fair bit of room *inside*
the enclosure.

>> There is no *need* to stick to the RJ45 form factor.  I think that severely
>> limits the choices and complicates the fitting of the connector to the
>> enclosure.
>
> There may not be any need, but the almost endless variety of mounting
> and protection configurations make the RJ45 connector a good choice.
> Put differently, why would you *NOT* want to use an RJ45 for ethernet?
> There has to be a very good reason to justify something different from
> the common ethernet connector standard.

Because of the environment and the enclosure I am *stuck* with.
DB25 was the standard for EIA232.  Why did it change?  Why can you
now find RxTx interfaces on 3mm phone plugs?  :-/

>> E.g., why are there mini-USB connectors instead of forcing ALL such connections
>> to adopt the standard A/B connectors?  (Ans:  because the mini connectors can
>> be deployed in locations that the standard ones can't!)
>
> I think you mean MicroUSB.  MiniUSB had problems.  Small connectors
> are a basic requirement on cell phones and portable devices.  You
> apparently don't have that requirement.
>
>> But, if that requirement complicates the connector choice, I can move the
>> power off the connector and handle it in other ways (power is relatively easy
>> and tolerant of a wide variety of connection methodologies)
>
> Speaking of power, I don't mind dealing with PoE (802.11af) at 48VDC
> because the source is properly protected from shorts and backfeeding

And, from bozos plugging telephones into the socket!

> power.  I do mind home made kludges, where someone uses the extra 4
> wires in the CAT5e cable for power.

You mean, Cisco?  :>

>  The resistance of the cable is
> usually high enough to prevent a fuse from blowing.  I've seen a few
> minor meldowns.  If you're going to do your own PoE thing, please
> design in some protection.

I implement alternatives 1 and 2 with some "enhancements" in the PD that
allows it to reinitiate the negotiation phase while still physically
connected.  And, a protocol that allows the PSE and PD to renegotiate
power required *and* available after the initial power class selection.

I.e., the device can effectively unplug itself and reconnect claiming
a higher/lower power class.  And, the PSE can elect to unconditionally
shed it as a load regardless of those prior negotiations.

   "I don't care what I promised you previously.  This is the new reality!"

On Fri, 05 Dec 2014 15:50:31 -0700, Don Y <this@is.not.me.com> wrote:

>The NID (Network Interface Device) tends to see very little physical access.

Thanks.  I couldn't recall the acronym.  I tend to use MPOE, Demarc,
and NID interchangeably.

You seem to be changing the specs as we go along.  Nothing was ever
mentioned about surviving a non-trivial number of insertion cycles.
The common RJ45 does reasonably well in this area.  Insertion cycle
specs vary, but I found a few data sheets offering 2500 cycles.
Hopefully, that's sufficient.
<http://www.mouser.com/pdfdocs/Amphenol_MRJR_Rugged_RJ45_Connector1.pdf>

>I suspect ours has been "opened" three times in 20+ years:  once when
>installed, once when we had some line problems and once when I changed the
>feeds into the house.

The RJ11/14 connector on my former Acterna tester probably had over
1,000 insertion cycles.  No problem.

>> For panel mount, something like this perhaps?
>> <http://www.newark.com/amphenol-ltw/rjs-5epffj-sc7008/connector-rj45-rcpt-8pos-panel/dp/48W0838>
>That's really pretty large (a consequence of RJ45!).  Looks like I'd need to
>find a clear area at least 3/4" - 1" dia.  Plus, a fair bit of room *inside*
>the enclosure.

Sorry, but they don't make connector shells with rectangular threads.
I vaguely recall seeing a product release on a rubber gasket to fit a
panel mounted RJ45.  However, that would only solve half the problem.
The mating plug also needs to be protected.  (I still vote for the
pigtail).

>> There has to be a very good reason to justify something different from
>> the common ethernet connector standard.
>
>Because of the environment and the enclosure I am *stuck* with.
>DB25 was the standard for EIA232.  Why did it change?  Why can you
>now find RxTx interfaces on 3mm phone plugs?  :-/

It was originally a DB25P/S.  Then, someone had a better idea and
expanded the connector to 37 pins:
<http://www.arcelect.com/rs449_interface_tutroial_and_pin%20outs.htm>
When IBM contrived the IBM PC, they also ran out of panel space on the
plug in cards.  So, they contrived a 9 pin RS232 connector.  Large
companies can do things like that without moral support from standards
committees.  However, when the multiport serial card manufacturers
needed something cheaper than an DB25 octopus, they went to the RJ45.
Well, not exactly.  They used the 10 pin RJ50 instead.  The connector
was also designed to use flat ribbon cable, that was reversible for
DTE and DCE wiring.  I was part of that mess, although my contribution
was trivial.  The 3.5mm jack came after I went on to other horrors:
<https://www.google.com/search?q=rs232+3.5+mm+jack&tbm=isch>
Who needs hardware flow control anyway?

>> Speaking of power, I don't mind dealing with PoE (802.11af) at 48VDC
>> because the source is properly protected from shorts and backfeeding
>
>And, from bozos plugging telephones into the socket!

Yep.  Extra credit to router manufacturers that simply ground the
unused 4 pins on the ethernet connector.  I don't have an answer to a
bozo proof connector system.

>> power.  I do mind home made kludges, where someone uses the extra 4
>> wires in the CAT5e cable for power.
>
>You mean, Cisco?  :>

Nope. Cisco is all 802.3af with no creative PoE.  Dlink, Netgear, and
Ubiquiti all invented their own PoE systems.  For example, the Dlink
DWL-P100 pair used 15VDC in to get 5VDC out.  Ubiquiti has various
voltages:
<http://www.ubnt.com/accessories/poe-adapters/>
PoE over 1000baseT is yet another complexication, where the DC power
needs to be shared with data lines.  Mixing systems usually results in
destroying something.

>I implement alternatives 1 and 2 with some "enhancements" in the PD that
>allows it to reinitiate the negotiation phase while still physically
>connected.  And, a protocol that allows the PSE and PD to renegotiate
>power required *and* available after the initial power class selection.
>
>I.e., the device can effectively unplug itself and reconnect claiming
>a higher/lower power class.  And, the PSE can elect to unconditionally
>shed it as a load regardless of those prior negotiations.

That's all in the 802.3af specification.  However, the real trick is
for the PSE to not deliver power until it has successfully negotiated
a current limit with the PD.  If the PSE lines are shorted, no power,
and therefore, no smoke.

>   "I don't care what I promised you previously.  This is the new reality!"

"Oh no... you did what I asked."

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On 12/5/2014 4:54 PM, Jeff Liebermann wrote:
> On Fri, 05 Dec 2014 15:50:31 -0700, Don Y <this@is.not.me.com> wrote:
>
>> The NID (Network Interface Device) tends to see very little physical access.
>
> Thanks.  I couldn't recall the acronym.  I tend to use MPOE, Demarc,
> and NID interchangeably.

I tend to prefer TNI (Telephone Network Interface)

> You seem to be changing the specs as we go along.  Nothing was ever
> mentioned about surviving a non-trivial number of insertion cycles.

I didn't mention spiders nesting in the connectors, either.  Nor leaf
cutting wasps stuffing leaf-wrapped eggs in them!  I pointed to the
primary issue:  weather resistance with an irregular shaped enclosure.
The fact that I decided the characteristics of the enclosure were worth
mentioning (and not just saying "outdoor application) and, IMO, ruled out
the RJ45 form factor should suggest I can't FIT an RJ45 to the enclosure:

     "an irregular-shaped (metal) enclosure"

     "suitable connection without requiring new castings"

     "tedious to machine *into* the case.  ABANDONING it for a more PHYSICALLY
     CONVENIENT connector leaves me uncertain as to how "untwisting" all those
     connections *at* the connector would compromise the signal path"

So, to use one, would mean dangling on a pigtail.  I.e., the issue is one
of moving to a DIFFERENT connector and still satisfying the SPECIFIC
wiring constraints that are imposed for RJ45's

> The common RJ45 does reasonably well in this area.  Insertion cycle
> specs vary, but I found a few data sheets offering 2500 cycles.
> Hopefully, that's sufficient.
> <http://www.mouser.com/pdfdocs/Amphenol_MRJR_Rugged_RJ45_Connector1.pdf>
>
>> I suspect ours has been "opened" three times in 20+ years:  once when
>> installed, once when we had some line problems and once when I changed the
>> feeds into the house.
>
> The RJ11/14 connector on my former Acterna tester probably had over
> 1,000 insertion cycles.  No problem.

Great.  If I ever want to site an Acterna tester outside, I'll know what to
use!

>>> For panel mount, something like this perhaps?
>>> <http://www.newark.com/amphenol-ltw/rjs-5epffj-sc7008/connector-rj45-rcpt-8pos-panel/dp/48W0838>
>> That's really pretty large (a consequence of RJ45!).  Looks like I'd need to
>> find a clear area at least 3/4" - 1" dia.  Plus, a fair bit of room *inside*
>> the enclosure.
>
> Sorry, but they don't make connector shells with rectangular threads.

Exactly.  The RJ45 form factor imposes constraints on the type of enclosure
ONTO which it can be fitted.

> I vaguely recall seeing a product release on a rubber gasket to fit a
> panel mounted RJ45.  However, that would only solve half the problem.
> The mating plug also needs to be protected.  (I still vote for the
> pigtail).
>
>>> There has to be a very good reason to justify something different from
>>> the common ethernet connector standard.
>>
>> Because of the environment and the enclosure I am *stuck* with.
>> DB25 was the standard for EIA232.  Why did it change?  Why can you
>> now find RxTx interfaces on 3mm phone plugs?  :-/
>
> It was originally a DB25P/S.  Then, someone had a better idea and
> expanded the connector to 37 pins:
> <http://www.arcelect.com/rs449_interface_tutroial_and_pin%20outs.htm>
> When IBM contrived the IBM PC, they also ran out of panel space on the
> plug in cards.  So, they contrived a 9 pin RS232 connector.  Large
> companies can do things like that without moral support from standards
> committees.  However, when the multiport serial card manufacturers
> needed something cheaper than an DB25 octopus, they went to the RJ45.
> Well, not exactly.  They used the 10 pin RJ50 instead.  The connector
> was also designed to use flat ribbon cable, that was reversible for
> DTE and DCE wiring.  I was part of that mess, although my contribution
> was trivial.  The 3.5mm jack came after I went on to other horrors:
> <https://www.google.com/search?q=rs232+3.5+mm+jack&tbm=isch>
> Who needs hardware flow control anyway?

103 modems.  RS232 came into being to allow IBM and ATT to "fit together".
The original interface imposed all sorts of details on the exact timing of
individual signal assertions and releases -- genuine handshakes not just
"status indications".  These quickly became bastardized as both ends of the
link got smarter.  And, as the types of comms equipment evolved.

>>> Speaking of power, I don't mind dealing with PoE (802.11af) at 48VDC
>>> because the source is properly protected from shorts and backfeeding
>>
>> And, from bozos plugging telephones into the socket!
>
> Yep.  Extra credit to router manufacturers that simply ground the
> unused 4 pins on the ethernet connector.  I don't have an answer to a
> bozo proof connector system.
>
>>> power.  I do mind home made kludges, where someone uses the extra 4
>>> wires in the CAT5e cable for power.
>>
>> You mean, Cisco?  :>
>
> Nope. Cisco is all 802.3af with no creative PoE.

Cisco *currently* may be that way.  But, legacy Cisco equipment predated
the PoE standards.  E.g., "here are some unused conductors in the cable;
let's push power down them".  Their "pre-PoE" PoE had a proprietary (in
the sense of "Cisco-specific") standard.  Much lower power and the
initial connection between the PD and PSE was negotiated via data
transactions (i.e., the PD had to "boot" almost immediately and
talk to the switch lest it not be powered as intended)

> Dlink, Netgear, and
> Ubiquiti all invented their own PoE systems.  For example, the Dlink
> DWL-P100 pair used 15VDC in to get 5VDC out.  Ubiquiti has various
> voltages:
> <http://www.ubnt.com/accessories/poe-adapters/>
> PoE over 1000baseT is yet another complexication, where the DC power
> needs to be shared with data lines.  Mixing systems usually results in
> destroying something.

PoE (and PoE+) support two power distribution alternatives -- A and B
(I guess that's more creative than "1 and 2"  :< ).   One scheme supplies
power from the PSE over the unused pairs (if "unused" in the normal
course of usage).  The other imposes them as a common mode voltage on
the data pairs (and, thus, is the only way that power can be
delivered when all 8 conductors are in use -- e.g., GbE).

Both alternatives require the PD to engage in the same sort of negotiation
when first connecting to the cable/network.  That negotiation allows the
PSE to know how much power the PD is requesting (device class) as well
as provide some protection against non-PD devices being connected
(telephones with RJ11's "accidentally" crammed into an RJ45).  Power
is not AVAILABLE on the cable until the PSE determines that is should
supply the power -- and how much.

>> I implement alternatives 1 and 2 with some "enhancements" in the PD that
>> allows it to reinitiate the negotiation phase while still physically
>> connected.  And, a protocol that allows the PSE and PD to renegotiate
>> power required *and* available after the initial power class selection.
>>
>> I.e., the device can effectively unplug itself and reconnect claiming
>> a higher/lower power class.  And, the PSE can elect to unconditionally
>> shed it as a load regardless of those prior negotiations.
>
> That's all in the 802.3af specification.  However, the real trick is
> for the PSE to not deliver power until it has successfully negotiated
> a current limit with the PD.  If the PSE lines are shorted, no power,
> and therefore, no smoke.

No.  The specification deals with *one* negotiation at time of connection.
Even data protocols built atop this "guarantee" the PD the amount of power
that it initially negotiated (device class) with the PSE.  So, if a PD
initially requests ~7W, it can't later ask for ~15W without (electrically)
disconnecting and starting a new negotiation (presumably for that 15W level).

Of course, the PSE can decide NOT to honor its request!  Now, the PD
is effectively "unpowered".  This means that PDs have to ask for the most
they will EVER need on their initial connection.  That can lead to an
oversized PSE "just to be safe".

I prefer to leave the policy decisions to the application.  If *it*
decides that it would be prudent to SHED some load (regardless of how
selfish that load happens to be in its power demands), it should be
able to do so.  Likewise, if a load needs more power, it should be
able to negotiate that regardless of its initial assumptions.

>>    "I don't care what I promised you previously.  This is the new reality!"
>
> "Oh no... you did what I asked."
>

Jeff Liebermann wrote:
> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
> <jchisolm6@earthlink.net> wrote:
>
>> Try it.  Take a patch cable, whack it in half and solder a DB9M and F in
>> line.  Run several GB of TCP traffic through it and watch the error
>> counts.  If you have access to the FW you could pull out more detail on
>> what lower level errors you are seeing.
>
> The easy way to test that is to find a 10/100baseT *MANAGED* ethernet
> switch, and use an SNMP MIB browser to look at the errors at the MAC
> (Data Link) layer.  There are plenty of SNMP tools available to do
> this.  Details, if anyone wants me to scribble something on the topic.
>

You should be able to use any old Ethernet MAC that supports
publishing  those counters. The managed switch just provides more likely 
instrumentation.

That is fine for testing, but at least where I am, nobody wants a
managed switch for deployed systems unless you have a solution to
guarantee the switch configuration pretty much without human
intervention.

This might seem an odd post, but these days, the line between testing 
and deployment is pretty fine.

A respectable BER fighure for Ethernet is 10^-10. Almost everything is 
even better than that.

> I used to do this for testing some rather marginal communications
> links.  For example, running 10 or 100baseT over greater than 100
> meter cable runs.  My favorite demo is to put connectors on both ends
> of a 1000ft roll of CAT5e or CAT6, and see if it works.  1000ft of
> 10baseT is easy, but 100baseT has NEXT (near end cross talk) problems.
>

I know this is just a test methodology,. but I'd avoid 1000 feet of 
copper for deployment unless you have a cable management system capable 
of keeping *everything* off those cables.

We do use 200 foot cables as a backup for 802.11 but they're purely
a security blanket at this point.

Optical is coming farther and farther downmarket. Run 4:1 media
redundancy and hope for the best :)

> I've never tried a DE9P/S connector pair for ethernet.  However, I
> have run 10baseT through the common 0.093 Molex nylon "power"
> connectors with good results.  The mechanical designer forgot to
> install an RJ45 jack on the case and wanted to use four spare pins on
> the power connector for ethernet.  I found no problems with any
> "impedance bump" at either 10 or 100baseT.  I also ran a BER (bit
> error rate) test over a cable with two such connectors inline, and
> found something like 5 errors after a 2 day run.  However, a Fluke
> cable certified failed the cable, which may be a problem.  My
> guess(tm) is that a DE9P/S connector pair will work.
>

I'd really just bypass the managed switch and go for the Fluke 
certifier. They're excellent. I have not measured *how* excellent, but I 
have no failures due to cables since we invested in one.

> Google Images for "military rj45".
> <https://www.google.com/search?q=military+rj45&tbm=isch>
> <https://www.google.com/search?q=Amphenol+LTW+rj45&tbm=isch>
>
> M12 to RJ45 ethernet adapter:
> <https://www.amphenol.com/about/news_archive/2012/104/>
> Note that it has only 4 pins.  More:
> <http://www.farnell.com/datasheets/1672292.pdf>
>
>
>

And again; we run M12 in very rugged environments ( outside, mobile
equipment, industrial environment, filthy-dirty ) and they work great.

The Fluke certifier loves 'em.

--
Les Cargill

On Sat, 06 Dec 2014 14:59:23 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>Jeff Liebermann wrote:
>> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
>> <jchisolm6@earthlink.net> wrote:
>>
>>> Try it.  Take a patch cable, whack it in half and solder a DB9M and F in
>>> line.  Run several GB of TCP traffic through it and watch the error
>>> counts.  If you have access to the FW you could pull out more detail on
>>> what lower level errors you are seeing.
>>
>> The easy way to test that is to find a 10/100baseT *MANAGED* ethernet
>> switch, and use an SNMP MIB browser to look at the errors at the MAC
>> (Data Link) layer.  There are plenty of SNMP tools available to do
>> this.  Details, if anyone wants me to scribble something on the topic.

>You should be able to use any old Ethernet MAC that supports
>publishing  those counters. The managed switch just provides more likely 
>instrumentation.

True.  However, the advantage of using a managed switch is that I can
carry it around with me, "tap" into any ethernet cable, and produce
immediate results without needing to install SNMP services on a target
machine.  Using a managed switch also allows me some control over NWAY
(Auto-Negotiation) negotiation and allows fixing the interface rate
and protocol.

>That is fine for testing, but at least where I am, nobody wants a
>managed switch for deployed systems unless you have a solution to
>guarantee the switch configuration pretty much without human
>intervention.

A "managed" solution seems to imply that there's someone around to do
the managing.  That usually means me.  However, you do have a point.
Most of my customers fail to appreciate receiving error logs via
email, and wouldn't know what to do with them anyway.  However, long
term monitoring is not my purpose here (although I do graphs with MRTG
and RRDTool, which my customers can easily understand).  Inserting a
managed switch, and using SNMP to collect numbers is for testing if a
creative cabling and connector scheme is likely to be usable.  Think
of it as a piece of test equipment, which is normally not left in the
circuit.

>This might seem an odd post, but these days, the line between testing 
>and deployment is pretty fine.

Customer tested products?  Yeah, I know the feeling.  When firmware
updates start to look like recall notices, I start to worry.

>A respectable BER fighure for Ethernet is 10^-10. Almost everything is 
>even better than that.

Well, let's see.  BER = 10^-10 at 100 Mbit/sec is about 1 error every:
   100*10^6 / 1*10^-10 = 1*10^4 = 10,000 seconds = 7 hrs
at the MAC layer.  For an office environment, I usually see about 1
error per day.  For a noisy industrial environment, maybe 10 errors
per day.  Yeah, that's in the ballpark.  Since the observed errors are
usually externally induced (i.e. power glitches), the error frequency
for 1000baseT is the same as 100baseT, resulting in a BER = 1*10^-11.

>I know this is just a test methodology,. but I'd avoid 1000 feet of 
>copper for deployment unless you have a cable management system capable 
>of keeping *everything* off those cables.

I didn't have much choice.  The run was through 3/4" PVC conduit,
across an open field, and through a plumbers nightmare at each end.
For various reasons, RF was unacceptable.  The conduit was crammed
full of cables and no more could be added.  However, there was one
existing CAT5e cable that was being used for a single POTS phone line.
I proposed to use the existing pairs for ethernet, without expensive
ethernet extenders:
<http://www.patton.com/ethernet-extender/>
The company experts declared this gross violation of industry
standards to be a capital crime, so I offered to demonstrate that it
would work using a new 1000 ft roll of CAT5e cable.  No problems at
all at 10baseT HDX (half-duplex) or FDX (full-duplex) .  100baseT was
iffy in FDX due to NEXT (near end crosstalk), but worked just fine
using HDX.  I vaguely recall posting a rant on the topic in
comp.dcom.wiring, and being accused of heresy or something.

I will admit that I had problems with duplex mismatch at one end of
the link, but that was solved by replacing an old 10/100baseT switch
with a newer one that correctly implemented auto-negotiation.

>We do use 200 foot cables as a backup for 802.11 but they're purely
>a security blanket at this point.

I have a spare pair of Ubiquity M5-HP bullet radios, panels, PoE, etc
for such occasions.  I also have at least 500ft of CAT5e handy for
wi-fi backup.  I use it sometimes for keeping a link up and running,
while I'm juggling radios, updating firmware, or trying to find
sources of interference.  However, mostly it's used for deploying an
added WAP (ireless access point) to extend coverage, while get someone
to do the CAT5e backhaul wiring.

>Optical is coming farther and farther downmarket. Run 4:1 media
>redundancy and hope for the best :)

Yep.  I've done some fiber.  The problem with a high fiber diet is
that it's still rather expensive and I have problems selling fiber to
my cheap customers.  Certainly not for residential work:
<http://802.11junk.com/jeffl/pics/drivel/fiber_01.jpg>
We do have some fiber running around the neighborhood as part of a
previous internet and CATV sharing system.  The fiber parts have
survived quite nicely.  However, fiber is no guarantee against assault
by mice, squirrels, back hoes, the water district, or falling trees.

>I'd really just bypass the managed switch and go for the Fluke 
>certifier. They're excellent. I have not measured *how* excellent, but I 
>have no failures due to cables since we invested in one.

I would love to own a Fluke certifier.  I can't justify the expense
and borrow one when the customer insists on testing.  Meanwhile, I use
a DC continuity tester to deal with my wiring errors, and a home made
TDR for finding cable defects and split pairs.  (The fun really began
when I wired one end of the cables for EIA-568B, while my accomplice
wired the other ends for EIA-568A).

>And again; we run M12 in very rugged environments ( outside, mobile
>equipment, industrial environment, filthy-dirty ) and they work great.
>
>The Fluke certifier loves 'em.

That's probably the right way to do it, but I find exploring the
creative and non-standard alternatives more interesting.

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

Jeff Liebermann wrote:
> On Sat, 06 Dec 2014 14:59:23 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> Jeff Liebermann wrote:
>>> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
>>> <jchisolm6@earthlink.net> wrote:
>>>
>>>> Try it.  Take a patch cable, whack it in half and solder a DB9M and F in
>>>> line.  Run several GB of TCP traffic through it and watch the error
>>>> counts.  If you have access to the FW you could pull out more detail on
>>>> what lower level errors you are seeing.
>>>
>>> The easy way to test that is to find a 10/100baseT *MANAGED* ethernet
>>> switch, and use an SNMP MIB browser to look at the errors at the MAC
>>> (Data Link) layer.  There are plenty of SNMP tools available to do
>>> this.  Details, if anyone wants me to scribble something on the topic.
>
>> You should be able to use any old Ethernet MAC that supports
>> publishing  those counters. The managed switch just provides more likely
>> instrumentation.
>
> True.  However, the advantage of using a managed switch is that I can
> carry it around with me, "tap" into any ethernet cable, and produce
> immediate results without needing to install SNMP services on a target
> machine.  Using a managed switch also allows me some control over NWAY
> (Auto-Negotiation) negotiation and allows fixing the interface rate
> and protocol.
>

I have yet to run into much that does not allow intervening in auto 
negotiation, managed or not.

>> That is fine for testing, but at least where I am, nobody wants a
>> managed switch for deployed systems unless you have a solution to
>> guarantee the switch configuration pretty much without human
>> intervention.
>
> A "managed" solution seems to imply that there's someone around to do
> the managing.  That usually means me.  However, you do have a point.
> Most of my customers fail to appreciate receiving error logs via
> email, and wouldn't know what to do with them anyway.  However, long
> term monitoring is not my purpose here (although I do graphs with MRTG
> and RRDTool, which my customers can easily understand).  Inserting a
> managed switch, and using SNMP to collect numbers is for testing if a
> creative cabling and connector scheme is likely to be usable.  Think
> of it as a piece of test equipment, which is normally not left in the
> circuit.
>

Sounds about right. Once you have the SNMP toolset, it's not hard to
establish your configuration. But these things confuse people.

>> This might seem an odd post, but these days, the line between testing
>> and deployment is pretty fine.
>
> Customer tested products?  Yeah, I know the feeling.  When firmware
> updates start to look like recall notices, I start to worry.
>
>> A respectable BER fighure for Ethernet is 10^-10. Almost everything is
>> even better than that.
>
> Well, let's see.  BER = 10^-10 at 100 Mbit/sec is about 1 error every:
>     100*10^6 / 1*10^-10 = 1*10^4 = 10,000 seconds = 7 hrs
> at the MAC layer.  For an office environment, I usually see about 1
> error per day.

Sure.

> For a noisy industrial environment, maybe 10 errors
> per day.  Yeah, that's in the ballpark.  Since the observed errors are
> usually externally induced (i.e. power glitches), the error frequency
> for 1000baseT is the same as 100baseT, resulting in a BER = 1*10^-11.
>


Thereabouts. IMO, the Ethernet interface is no longer the source of most 
errors these days.

>> I know this is just a test methodology,. but I'd avoid 1000 feet of
>> copper for deployment unless you have a cable management system capable
>> of keeping *everything* off those cables.
>
> I didn't have much choice.  The run was through 3/4" PVC conduit,
> across an open field, and through a plumbers nightmare at each end.
> For various reasons, RF was unacceptable.  The conduit was crammed
> full of cables and no more could be added.  However, there was one
> existing CAT5e cable that was being used for a single POTS phone line.
> I proposed to use the existing pairs for ethernet, without expensive
> ethernet extenders:
> <http://www.patton.com/ethernet-extender/>
> The company experts declared this gross violation of industry
> standards to be a capital crime,

LOLz!

> so I offered to demonstrate that it
> would work using a new 1000 ft roll of CAT5e cable.  No problems at
> all at 10baseT HDX (half-duplex) or FDX (full-duplex) .  100baseT was
> iffy in FDX due to NEXT (near end crosstalk), but worked just fine
> using HDX.  I vaguely recall posting a rant on the topic in
> comp.dcom.wiring, and being accused of heresy or something.
>
> I will admit that I had problems with duplex mismatch at one end of
> the link, but that was solved by replacing an old 10/100baseT switch
> with a newer one that correctly implemented auto-negotiation.
>


Yep.

>> We do use 200 foot cables as a backup for 802.11 but they're purely
>> a security blanket at this point.
>
> I have a spare pair of Ubiquity M5-HP bullet radios, panels, PoE, etc
> for such occasions.  I also have at least 500ft of CAT5e handy for
> wi-fi backup.  I use it sometimes for keeping a link up and running,
> while I'm juggling radios, updating firmware, or trying to find
> sources of interference.  However, mostly it's used for deploying an
> added WAP (ireless access point) to extend coverage, while get someone
> to do the CAT5e backhaul wiring.
>
>> Optical is coming farther and farther downmarket. Run 4:1 media
>> redundancy and hope for the best :)
>
> Yep.  I've done some fiber.  The problem with a high fiber diet is
> that it's still rather expensive and I have problems selling fiber to
> my cheap customers.  Certainly not for residential work:
> <http://802.11junk.com/jeffl/pics/drivel/fiber_01.jpg>

Probably not in residential.

> We do have some fiber running around the neighborhood as part of a
> previous internet and CATV sharing system.  The fiber parts have
> survived quite nicely.  However, fiber is no guarantee against assault
> by mice, squirrels, back hoes, the water district, or falling trees.
>
>> I'd really just bypass the managed switch and go for the Fluke
>> certifier. They're excellent. I have not measured *how* excellent, but I
>> have no failures due to cables since we invested in one.
>
> I would love to own a Fluke certifier.  I can't justify the expense
> and borrow one when the customer insists on testing.  Meanwhile, I use
> a DC continuity tester to deal with my wiring errors, and a home made
> TDR for finding cable defects and split pairs.  (The fun really began
> when I wired one end of the cables for EIA-568B, while my accomplice
> wired the other ends for EIA-568A).
>

A TDR is just fine so long as you know what to look for and it supports
the right cable profiles. I think the certifier we have is like $1K. 
Might be less - there are a lot of them.

Not having one probably cost us at least an order of magnitude more.

>> And again; we run M12 in very rugged environments ( outside, mobile
>> equipment, industrial environment, filthy-dirty ) and they work great.
>>
>> The Fluke certifier loves 'em.
>
> That's probably the right way to do it, but I find exploring the
> creative and non-standard alternatives more interesting.
>

These days, I just want the phone not to ring :)

-- 
Les Cargill