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

Re: [802.3_4PPOE] Base Line proposal - 802.3bt End to End Channel P2P Resistance Unbalance ad hoc



Ken,

 

I added one comment below.  I also suggest that if there is another method of specifying PSE or PD offset, that it be vetted against the model I have shown to look for the ‘corners’.  I have seen no specific proposal for a specification yet so when this does happen, we can look things over then.

 

 

Regards,

 

Jeff Heath
Design Center Manager

Description: Linear Technology Corporation

 

 

paper:

402 East Carrillo Street, Suite D

 

Santa Barbara, California 93101

voice:

805.965.6400

fax:

805.965.1701

computer:

jheath@xxxxxxxxxx

 

www.linear.com

 

 

From: Ken [mailto:ken_bennett@xxxxxxxxx]
Sent: Monday, May 05, 2014 5:28 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Base Line proposal - 802.3bt End to End Channel P2P Resistance Unbalance ad hoc

 

Hi Jeff,
Thank you for your comments.  I've added some follow-up comments.
Best Regards,
Ken

On 5/2/2014 5:20 PM, Jeff Heath wrote:

Hi Ken,

 

I agree with nearly everything you said.  I have the following comments:

 

When specifying a PI as a black box the specification needs to include all ‘current ranges of interest’ whatever they may be.  If we use discrete points, interoperability is not guaranteed from a spec standpoint.  Testing on the other hand cannot test every current in a range.  I am generally of the opinion that a specification needs to cover the range.  The test from a practical matter does not and there is always a leap of faith.

Ken: I agree that all current ranges of interest may not be practical in a given test.  Testing to a worst case limit is often sufficient if the parameters have a reasonably linear response.  A second discrete measurement point may be warranted in some situations, for instance, for a PSE, an unbalanced current near the top of a PSE's power range and a balanced current at the low end (maybe 2x MPS) could be used for the Voltage limit tests.  If a linear response is assumed, as it would be in the case of P2PRUNB, then this should suffice.

 

A hypothetical example of this might be the testing of DC disconnect.  The spec is very clear.  The PSE must not turn off a PD if the current is above 10mA for 60mS (in a given period).  One can test with 10mA but it is generally not necessary to test again at 11mA, 12mA …  

 

Ken: I agree

If however a PSE is mis-designed, and let’s say turns off a PD at 20mA, a tester may not catch it for the above reason, but a test could be done to show that the PSE is out of specification and therefor at fault from an interoperability perspective.

Ken: If a test is successful at 10mA and the PSE turns a PD off at 20mA, a test certainly might miss this.  In the past, suggested tests in the Annexes were informative and not actual requirements.  There is always some responsibility  placed upon the designer to meet a spec, and that may involve testing scenarios which may not be applicable to all devices.  For example, If a PSE MPS is compliant at 10mA and shuts off a PD at 20mA, it would presumably be caused by something inherent to the design; a designer would have knowledge of whatever unique feature would cause the issue and would hopefully tailor the test to focus in that area.  If a PSE or PD has auto-balancing circuitry that turns on at some level, then the device should be tested around that level as well as the worst case.

 

JLH new comment: I think you are right about a correct design in almost all cases.  Still, as long as the specification is clear, we know where to point the finger in the case of interoperability issues.



 

However we end up specifying the PSE and PD PIs, I think we need clear specifications and operating conditions that cover the subject, and not a discrete set of points within whatever range we choose to specify current imbalance.

Ken: I agree.

 

 

 

Regards,

 

Jeff Heath
Design Center Manager

Description: Linear Technology Corporation

 

 

paper:

402 East Carrillo Street, Suite D

 

Santa Barbara, California 93101

voice:

805.965.6400

fax:

805.965.1701

computer:

jheath@xxxxxxxxxx

 

www.linear.com

 

 

From: Ken [mailto:ken_bennett@xxxxxxxxx]
Sent: Friday, May 02, 2014 5:52 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Base Line proposal - 802.3bt End to End Channel P2P Resistance Unbalance ad hoc

 

Hi All,

Here's some follow-up thoughts to consider regarding yesterday's Runbalance spec discussion:

1.  In 802.3af/at, Runbalance was easily and necessarily defined, since it could focus only on resistance of wires and the points between the port and the power taps.  That spec applies pretty universally to all devices.

2.  An Runbalance spec exists primarily to address Iunbalance.  Previously, Runbalance alone could be used to determine Iunbalance.  This is not the case with 4-pair; other factors include:

    2a) PSE Case:   Voltage differences at the PSE output.  Voltages are not inherently equal and can have a greater effect on Iunbalance than Runbalance does.  Specifying a worst case Voltage unbalance at a specified current loading, may be more appropriate because it would inherently include PSE Runbalance.  Conversely, specifying PSE Runbalance alone does not remove the need to have a Voltage unbalance spec.

   2b) PD Case:  As in the PSE case, Runbalance alone at the PD input is not solely responsible for PD contribution to Iunbalance.  Implementation flexibility imposes many potential influences.  Other items mentioned below also factor in.

3.  There are cases where an Runbalance spec at a PD PI is an unnecessary and perhaps burdensome requirement.  Examples where PD PI Runbalance doesn't matter are:

    3a) (As mentioned in the meeting) there may be PD's under a (TBD) power limit with inherent Iunbalance between pairs (ie a 200mA/100mA split)

    3b) Some of the architectures under consideration (ie. x2 PD's)

    3c) PD's implementing Iunbalance correction circuitry

4.  PD PI Runbalance Testability is complicated.  If a test method is suggested, it should focus on testing under a powered-on condition because 1) this is where it matters, and 2) the resistance at Powered-on Voltages can be different than resistances at unpowered Voltages.  A PD PI test recommendation ideally would be doable under normal operating conditions without having to probe circuits or develop special test modes.

There's a fundamental problem with testing PD powered-on input resistance: a PD can and typically does present a load which varies over time.  If a test is proposed which involves sequential measurements, it will be prone to error due to varying loads.  A simple straightforward test would be to impose a Voltage on all four pairs and measure the currents.  This would allow a resistance calculation free of errors.  Note however that this is essentially doing a current unbalance measurement for the purpose of calculating resistance, which in turn is used for determining current unbalance.  Why not simply impose a maximum current unbalance spec at specified Voltage inputs?

To summarize,

1)  Runbalance spec of a cable...   no problem.
2)  PSE's: it may be more appropriate to specify a Voltage unbalance at specified currents
3)  PD's: it may be more appropriate to specify current unbalance at specified Voltages, with allowances for PD's under TBD watts.
4)  PI Runbalance work done thus far can certainly be used as a basis for specifying the test currents and Voltages, but it doesn't need to be an additional spec.

Best Regards,
Ken



On 5/1/2014 8:23 AM, Darshan, Yair wrote:

Hi team,

 

Attached please find the meeting material for today in addition to what was send already today. Total 3 files.

 

Regards

 

Yair

 

 

Yair

802.3bt End to End Channel P2P Resistance Unbalance ad hocAd hoc chair.

 

-----

Darshan Yair

Chair

Power over HDBaseT Subcommittee

HDBaseT Alliance

 

Chief R&D Engineer

Analog Mixed Signal Group

Microsemi Corporation

 

1 Hanagar St., P.O. Box 7220
Neve Ne'eman Industrial Zone
Hod Hasharon 45421, Israel
Tel:  +972-9-775-5100,

Cell: +972-54-4893019
Fax: +972-9-775-5111

 

E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>.