Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #431047

Re: "On-line" 100BaseTX hardware diagnostics

Cross-posted to 2 groups.

Show all headers | View raw

On 10/12/2016 3:47 PM, Robert Wessel wrote:
> On Wed, 12 Oct 2016 12:33:12 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> What sorts of hooks can I include in my designs to allow
>> run-time testing of 100BaseTX hardware?
>>
>> Obviously, I can monitor traffic, throughput, CRC errors,
>> etc. to give me a feel for degradation of the overall link.
>>
>> But, what can I do to diagnose things like cabling problems
>> and failures without impacting the quality of the link
>> hardware "otherwise"?  (think "built in cable tester")
>>
>> An even tougher question:  can I leverage a *partially*
>> functional cable/interface to provide *limited* connectivity
>> in the event of a failure that impacts the normal NIC-pair?
>> (even if this is an either-or implementation)
>
> Well, other than trying to fall back to 10Mb mode (which will be a
> smidge more tolerant of marginal cables), not really, at least not
> without something on both ends of the wire.

I'm asking what I can add on both ends (I own the switch's design)
to accomplish this.  The "degraded capability" is just something
that I would need to allow the remote device to "get a message
through" to some other device that could convey that information
to the user (devices don't have UI's).

Rather than just saying "something is wrong with SOME ASPECT of
the communication link with device X" -- which could be switch
related (including cable-end and connection), cable related
(including placement and interference from a poor installation)
or "remote device" related (etc.)

I'd NOT like to have to force the remote device to be removed
and checked if the problem happens to be closer to the switch, etc.
(and the opposite case is also true)

> OTOH, if you *can* put something on both ends of the wire, why not
> just put a second 100Mb MAC/PHY on your device, and wire it to the
> other* four wires, and then split the far end of the cable into two
> RJ-45s, and plug both of those into the switch (or better yet, plug
> them into separate switches, for redundancy).

Adds a significant cost to the system.  PoE switch with PTP support.
Add a *second* one (i.e., ANOTHER 70 ports?)

I'm hoping the two spare pairs are a safety net if I need to
replace a bad data pair or move to Mode B for power delivery.

> Or just put two Ethernet ports on your device, and let the user run
> two cables for redundancy, or use a cable split on both ends to use a
> single physical cable which would tolerate some damage (or a plain
> cable if they care about neither).
>
> Splitters are available off the shelf for just that sort of
> application (two Ethernet drops on one cable).
>
> Anything else you might do (run RS-422 serial over the unused pairs?
> autosense for a subset of working wires?), will require custom
> hardware at the switch end as well (and I doubt it'll cost less to do
> than just having a second switch).  And it's hard to imaging that you
> could actually add a serial port to your device for meaningfully less
> than a second Ethernet MAC/PHY.

Many SoC's *have* serial ports -- that I'm not using.  So, it's really
just the cost of any level translators, isolation, etc. that MIGHT be
involved.

The "secondary channel" is intended as a fall back only for diagnostic
purposes.  So, needn't be very high bandwidth (e.g., a Bell 103 modem
would MORE THAN suffice).  Consider the alternative:  an idiot light that
the user examines and conveys the information MANUALLY to <whatever> for
resolution

(damn near anything is higher bandwidth than involving the user!)

The problem is getting whatever "backup" communication mechanism
to coexist with the PHY.  It can't interfere with (or distort)
"normal" comms when everything is working properly.  And, I need
to be able to ensure the PHY (possibly in a failed state!) doesn't
compromise that secondary channel

And, to do so without adding considerably to cost/complexity.

(a digital I/O could be toggled at something just this side of DC
and suffice -- were it not for the isolation and protection issues)

> A combination of a wired Ethernet port and a WiFi port has some
> attractions as well, especially given how much people hate pulling
> cables.

Hard to deliver power over wireless!  :>  (and, having dozens of
wallwarts scattered around each delivering a few watts to its
respective load would represent another hassle:  did someone knock
a wall wart loose?  Did it fail?  Did the outlet into which it was
plugged get witched off?  Has the circuit "blown"?  Is there a
power outage?  etc.

> *Obviously that won't work with GigE, which uses all four pairs.

As would 10/100BaseTX with Mode B PoE (my fallback if Mode A doesn't
cut it for a particular drop)

Back to sci.electronics.design | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

"On-line" 100BaseTX hardware diagnostics Don Y <blockedofcourse@foo.invalid> - 2016-10-12 12:33 -0700
  Re: "On-line" 100BaseTX hardware diagnostics Grant Edwards <invalid@invalid.invalid> - 2016-10-12 20:33 +0000
    Re: "On-line" 100BaseTX hardware diagnostics Don Y <blockedofcourse@foo.invalid> - 2016-10-12 15:48 -0700
  Re: "On-line" 100BaseTX hardware diagnostics Robert Wessel <robertwessel2@yahoo.com> - 2016-10-12 17:47 -0500
    Re: "On-line" 100BaseTX hardware diagnostics Don Y <blockedofcourse@foo.invalid> - 2016-10-12 16:07 -0700

csiph-web