Re: [802.3_SPEP2P] EXTERNAL: Re: [802.3_SPEP2P] AW: AW: [802.3

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Steffen & David – Thanks for the detailed info.

George – I absolutely agree when you say “we don't actually specify lengths of cabling or numbers of connectors but rather the electrical characteristics of the link segment”, BUT, we need to understand possible implementations to help us choose a link segment that enables our economic viability (i.e., addresses a sufficient large market to be interesting).

What I’m trying to understand is the “best practice” for building these systems so that I can make an informed judgement about firstly the objectives we set for ourselves, and secondly the link segment spec when we get to it.

Speaking for myself, I’d really like to see some of this information come into the group as presentations which can be a little easier to reference than reflector discussions.

Regards
Peter

_________________________________________________________

Peter Jones Cisco Systems

Distinguished Engineer 170 West Tasman Dr.

Enterprise Networks San Jose, CA, 95134, USA.

Wrk: +1 408 525 6952 Mob: +1 408 315 8024

Email: petejone at cisco.com

Web: about.me/petergjones

Webex: cisco.webex.com/join/petejone

_________________________________________________________

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Sunday, July 4, 2021 9:44 AM
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPEP2P] EXTERNAL: Re: [802.3_SPEP2P] AW: AW: [802.3_SPEP2P] Number of link segment in-line connectors

FYI, where autocorrect put in SPMD, please read that as SPD - surge protective devices

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

On Jul 4, 2021, at 9:33 AM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

Steffen - just a short note as we are on holiday today and tomorrow (at least partly) in the us. The subject of surge protection in 802.3 is complicated. There are other ieee groups (completely outside of 802) who have responsibility for this. You may have heard some discussion of that in the ieee 802.3 pdcc ad hoc, or the 802.3cr effort.

However, the transmission characteristics (as opposed to the protection characteristics) of SPMDs can be an issue, and, if we expect them to be frequently used, we should try to make sure that those transmission characteristics are adequately specified - hence my note. We can discuss further. I am less concerned about capacitance as that is a linear effect and can be completely included in the link segment specifications. this is one reason why you find me continually reminding people we don't actually specify lengths of cabling or numbers of connectors, but rather the electrical characteristics of the link segment - you can make trades ( shorter reach, less lossy cabling or connectors) when you use auxiliary devices such as SPMDs which introduce additional loss and/or reflections.

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

On Jul 4, 2021, at 12:59 AM, Steffen Graber <steffen@xxxxxxxxxxxxx> wrote:

Hi George,

even if this now goes down into how Ethernet-APL implements surge protection, I think a short explanation could help here:

For surge protection we were most concerned about the capacitance at the MDI (the Ethernet-APL port).

So for Ethernet-APL we decided to split the surge protection device into the surge suppressor diode (which has by far the highest influence on a 10BASE-T1L signal, as these devices may have a significant capacitance and we did not want to add a second surge protection diode in teh external module) and the surge protection module itself containing the gas discharge tubes (GDTs).

The internal surge protection diode of an Ethernet-APL ports has to be able to withstand at least 25 A differentially. This diode always has to be present directly at the MDI connector within an APL field device, independent, if an external surge protector is used or not, as this diode is also required to meet the industrial EMC surge test requirements anyhow. Typically there also will have to be several bipolar series diodes which can be used to reduce the capacitance of this diode (with a good implementation I would expect a maximum differential capacitance of less than 40 pF, for 10BASE-T1L we could go up even higher, but for sure not for a 100 MBit/s system, where the capacitance likely would even need to be further optimized, likely having to go down into the 10 pF range).

The external part of the surge protection (what's in the surge protection device) are the gas discharge tubes, typically one between shield and ground and another differential 3-pin one between the data lines with the root of it connected to a second GDT with a higher voltage to ground (the reason for the series connection is that a surge protector must isolate the data pair with 500 V to ground in intrinsically safe applications).

These GDTs only have a very low capacitance in the range of 5 pF or less and ignite at high voltages only (typically 90 V or higher). So practically these have no relevant impact, at least for 10BASE-T1L. In Ethernet-APL the surge protection modules might also have some additional IL, as an implementer might choose to add e.g. 2 x 1 R resistors in series to coordinate the GDTs with the surge protection diode in the devices, but this would start to limit reach (mainly because of the voltage drop and also lead to significant power losses within the device for a trunk surge protector; so this is likely not what most of the implementers will use). As the surge is put onto the shield only, the effect on the internal data pair of the cable is pretty limited in a symmetric twisted pair system, so that even when applying a 10 kA surge on the shield, the differentially measured values at the diode are only in the range of a 30-40 A pulse, but much shorter than 8/20 µs and thus a 25 A differential diode suitable for a 8/20 µs pulse is expected to work on these events without the need for additional coordination.

Not having Ethernet-APL surge protection devices so far available on the market, we used a prototype breadboard setup with the GDTs to test the potential influence of an external surge protection module on 10BASE-T1L. During these tests we have not seen a relevant influence on either the MSE or the peak error value at the slicer. There was a very slight change visible in the peak error (at the 4th position after the comma for a normalized value) and a pretty small change in the echo canceller taps, but I would expect this to be mainly related to the breadboard "layout".

For the surge protection diodes within the Ethernet-APL ports it is important to set the clamping voltage of these diodes some volts above the normal operating voltage of the port. If this is not implemented correctly, this can cause significant distortions due to the non-linear diode leakage currents, especially at higher ambient temperatures, if there is not enought headroom. The Ethernet-APL conformance tests introduces a signal distortion test (originally introduced to check the behavior of the inductor clamping diodes), which I would expect to also catch the distortion of a wrongly designed surge protection diode within an Ethernet-APL port.

So back to your questions:

1. Having the surge protection diode in the devices with a not appropriately high clamping voltage, this effect will be visible (but could be solved by staying with the stand-off voltage of the diode some volts above the maximum supply voltage of the port). But this is under control of the device vendor. For the surge protection devices including the GDTs I would expect most of the influence coming from the layout or potential crosstalk effects from nearby segments having a capacitive coupling between the surge protection moduls, which especially at higher frequencies could require shielding measures.

2. Use higher voltage surge protection diodes and keep the split between the diode and surge protection device as already defined for Ethernet-APL 10 Mbit/s.

Most important likely is not to limit the overall capacitance at the MDI and keep the capacitance of the surge protection module low. So it must be checked, what maximum capacitance would be possible for a 100 Mbit/s system (for 10BASE-T1L the max. MDI capacitance to meet the MDI RL spec is about 300 pF). Technically reasonable for 100 MBit/s implementation including the inductor clamping and EMC measures for 100 Mbit/s could be in the range of 50 pF (getting lower might from my point of view become difficult in powered systems with higher EMC demands).

Regards,

Steffen

Am 02.07.2021 um 18:36 schrieb George Zimmerman:

Steffen –

This is really somewhat off topic for the SG, and getting into implementations, but you raise a problem I have seen a few times over the years.

Several times over the years it has come up that the echo cancelled PHY world has implicitly assumed that the link segment response is linear. However, surge protectors may contain nonlinear devices. SPMDs actually aren’t the only source of nonlinearity, for example, an ill-fitting oxidizing connection can do the same thing. For traditional, low-rate systems, particularly non-echo-cancelled ones, this really only shows up as insertion loss, and the nonlinear echo doesn’t matter. However, in my experience, the nonlinear echo can have performance-limiting impacts on echo-cancelled systems, creating a residual echo floor for any system using linear echo cancellation. It shows up mainly at long reach, but, is an UNSPECIFIED impairment. In the cases I dealt with it in the past, the protection devices were within the equipment (we would say on the PMA side of the MDI – although these weren’t Ethernet), and therefore at least the near-end was completely under control of the equipment manufacturer. However, if we put surge protectors into the link segment, we probably need a linearity specification on the reflected component. This will ultimately relate to powering voltages and other implementation-specific effects, but may need work in 802.3.

My question for you is: 1) have you seen this effect? (it would show up on very long links as some surge protectors causing reach loss greater than their insertion loss would indicate) and 2) do you have thoughts on specifying such an impairment.

If so, we may wish to consider a specific objective for compatibility with surge protection practices in the link segment. (I’m trying to write it general – I expect that we can’t be compatible with all)

-george

From: stds-802-3-spep2p@xxxxxxxxxxxxxxxxx <stds-802-3-spep2p@xxxxxxxxxxxxxxxxx> On Behalf Of Steffen Graber
Sent: Friday, July 2, 2021 12:16 AM
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: AW: Re: [802.3_SPEP2P] EXTERNAL: Re: [802.3_SPEP2P] AW: AW: [802.3_SPEP2P] Number of link segment in-line connectors

Hi Peter,

I agree with what David said in his response about surge protection and thanks David for your detailed explanations on this.

Related to the inline connectors, they are typically not equally spread across the length of the cable, but several may concentrate at the beginning or end of the segment, e.g.:

Power Switch in cabinet – 1-3 m Cable – Surge Protector in bottom area of cabinet – 30 cm Cable – Inline Connector (IC) at bottom of cabinet – 10-20 m Cable – IC in Marshalling Rack – 100 m Cable – IC in intermediate Fieldbox – 275 m – IC in intermediate Fieldbox – 100 m – IC at Entry of Field Box – 30 cm – Surge Protector – 30 cm – Field Switch.

Depending on the installation, mostly the power switches (these who provide data and power to an Ethernet-APL Segment) will be located in a large cabinet, typically up to 3 m in height and 1 top 1.5 m in width. In such installations, typically the power supplies for the switches are in the top rows, then the switches will come and at the bottom of the cabinet, there will be an (optional) row for the surge protectors and often an intermediate connector row, where it goes out of the cabinet (the layout within the cabinet could be different, but for preinstalled cabinets, there is typically such a common connection point for all the cables going in). The background for having this intermediate connector row is, that in this case, the complete cabinet can be pre-mounted before delivery to the construction side and that then just the cables coming from the field have to be hooked up all at the same point, which eases installation.

Then depending on how the plant is designed, there might be a further Marshalling Rack, especially in brown-field applications, where e.g. fieldbus or 4-20 mA applications should be replaced. This are racks, where the cables can be physically routed between the switch cabinets and the cable bulks going out into the field. These racks are typically some meters (e.g. 10-20 m cable distance away from the other cabinets, in the same control room or in a neighbored room.

From there it goes the larger distance into the field, where the field box including the field switch(es) are.

At the destination point, typically the cable again goes to a pre-mounted field box, where there is an intermediate connector where the cable is connected to the complete box, then there might be an (optional) surge protection and from that point it goes to the trunk input of the field switch.

Above example shows, that, even if only 2 intermediate connectors are really needed in this example to handle the long distance run, in total up to 5 ICs + 2 for the surge protection devices are needed to build the segment.

This might be optimized (e.g. by removing the marshalling cabinet, which in new installations typically will not be there to remove the number of needed connectors by one, but will still be needed when upgrading older installations).

Regards,

Steffen

To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1

To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1

To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1