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

Hi Ken,


Thanks for the response.

I will study your proposal and respond later due to pressure of time. I'll add this to the adhoc agenda so it will be addressed.






From: Ken [mailto:ken_bennett@xxxxxxxxx]
Sent: Monday, May 05, 2014 3:49 PM
To: Darshan, Yair; 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 Yair,

Thank you for your feedback.  I understand your points below, however I'd like to respectfully suggest the following alternate approach to the problem:

1)  Determine P2PRUNB at the PSE PI and PD PI, based upon the analysis done thus far and any TBD final adjustments.  The results effectively form baselines for designs that do not have special balancing circuits, and if related specs are based upon these, there would be no forcing of unnecessary circuitry.

2)  Use P2PRUNB in the system analysis that determines limits for PSE Voltage and PD current unbalance specs, but don't separately require PI P2PRUNB as a spec which has to be met and tested.  The PSE Voltage and PD current unbalance specs could be in the form of an equation which uses the unbalance ratios derived from the PI P2PRUNB values without actually incorporating resistance unbalances.

The complications of PSE and PD PI P2PRUNBAL applicability and testability would be avoided, while still taking the PI P2PRUNBAL analysis into account.   PSE Voltage and PD Current unbalances will eventually need to be specified, and direct measurements would also account for influences in addition to the PI P2PRUNBAL's.

If there are implementations that fall outside the applicability of the above approach, this could certainly be noted in the standard and addressed separately.

Best Regards,

On 5/3/2014 9:52 PM, Darshan, Yair wrote:

Hi Ken,


I like your summary and I propose that you make a presentation out of it for the IEEE meeting.

It covers many important issues.

Please see below in lines, my response to the points you have raised.








From: Ken [mailto:ken_bennett@xxxxxxxxx]
Sent: Friday, May 02, 2014 3:52 PM
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.

Yair: Agree.


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.
Yair: Agree.

   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.

Yair: Agree.

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:

Yair: Absolutely correct.

    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)

Yair: Absolutely correct.

    3c) PD's implementing Iunbalance correction circuitry

Yair: Absolutely correct.

4.  PD PI Runbalance Testability is complicated.

Yair: Fully agree. That’s why from managerial point of view, I believe that we first need to :

-Specify what is the new parameter that we need to add to the spec e.g. PSE PI P2PRUNB. AND THEN NEXT ON SEPARATE MOTION:

-Specify the value(s) of the new parameters. AND THEN NEXT ON SEPARATE MOTION:

-Specify test method/procedure for compliance test if needed (most of parameters doesn’t need it).

This strategy ensures that we are proposing text based on solid work and broad understanding of the problem.


  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.
Yair: Absolutely correct. I would add that so far all the work we did on P2PRUNB was derived from concerns during POWER_ON state.

If there is a need to define P2PRUNB during other system states such classification or MPS etc., it should be done in separate work, separate motions based on doing some work first  and not tie it to what we do now. ---------------------
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?

Yair: The big problem when you specify a maximum current unbalance spec e.g. on PD, you actually requires PD to have kind of current sharing/balancing circuitry (active or passive) and this is forcing implementation while in most cases it is not required. We must have a spec that (a) not limiting implementations of PDs (b) not forcing implementation. I believe that it can be done. From network circuit theory we need to define the worst case DC INPUT RESISTANCE UNBALANCE this should include all effects including diode bridge voltage difference which can be specified as Pair to pair PD input voltage offset difference etc. I don’t see analytically how you can specify P2P CURRENT UNBALANCE and avoid forcing implementations and more over getting into all the troubles that you have mentioned and there are much more..


To summarize,

1)  Runbalance spec of a cable...   no problem.

Yair: Agree.


2)  PSE's: it may be more appropriate to specify a Voltage unbalance at specified currents

Yair: Agree.

3)  PD's: it may be more appropriate to specify current unbalance at specified Voltages, with allowances for PD's under TBD watts.


-If PD power is below a level that the current of each 2P is less than 600mA then this is equivalent to 2P operation, therefore P2PRUNB of PD PI is embedded in this behavior so no need to ask PD to meet it.

- Above this PD power level, PD need to meet the requirements addressing PD PI P2PRUNB. (Regardless what are the details of it, it has to meet them)

So far is for the high level requirements. Once we agree on the concept we can go to the details etc.

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,

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.








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



Darshan Yair


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>.