Hi all,
The PSE power requirement is to guarantee PClass_PD at the PD PI.
A PSE can choose to assume worst-case V_PSE and Rchan and provide the power levels in Table 33-13.
However, as can be seen from Equation 33-2, the PSE may also choose to take V_PSE and Rchan into account to determine the amount of power it needs to provide.
Especially given the higher power levels we will support, this is a useful feature and must be allowed.
HOW the PSE determines Rchan is out of scope, it only matters that it does so correctly.
To test for compliance, a PSE can be loaded with a PClass_PD load (at the PD PI) using different channel resistances. Rchan may even dynamically change. As long as the PSE does not turn off the load, it is compliant.
This has been the case since 802.3at.
Most PSEs don't bother with Rchan and assume a worst case value.
Kind regards,
Lennart
Sent: Monday, January 9, 2017 16:50
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
George & Yair:
The following from George’s message IS, to me, the key point:
a) There is a dependence on Vpse as well. – that seems OK to me, it is a parameter of the PSE that can be controlled by the PSE itself.
b) There is a dependence on Rchan, but, (Peter thinks, and I believe from the below Yair may disagree) any PSE that tries to use the area of the template that applies for Rchan less than the maximum would fail the compliance test.
The PSE “controls” Vpse – it is known when the PSE is designed. So it seems natural for the PSE to take advantage of that knowledge when scaling Icon, Ipeak and any associated unbalance currents.
The PSE does NOT control Rchan, so hence my reason for saying a conformance test assumes maximum Rchan as that is the worst case in terms of current capacity. I expect there will be the counterpoint that a PSE could “magically” know Rchan, but unfortunately any such mechanism is outside the scope of the standard and therefore cannot be readily gauged by any standardized test.
John Skinner from Sifos will be at the meeting this week – he should be up to speed on this topic.
Regards,
Pete J
Sifos
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Sunday, January 08, 2017 3:03 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Looks like we should discuss this in person next week. When I read your responses what I think I understand is that:
We are talking about whether the region bounded by: ILIM_2P_min > IPort_2P > IPeak_2P and TLIM_2P_min < t < Tcut_2P_min is within the bounds of a valid PSE template or out of bounds.
The current draft says that it is within bounds, and that creates a dependence (at least) on Rchan
David Abramson says “everybody has figured out” that this region (his “red square”) is to be avoided, and therefore there is no problem (which, to me seems in contrast to putting it “in bounds” in the draft).
Peter and Yair point out:
a) There is a dependence on Vpse as well. – that seems OK to me, it is a parameter of the PSE that can be controlled by the PSE itself.
b) There is a dependence on Rchan, but, (Peter thinks, and I believe from the below Yair may disagree) any PSE that tries to use the area of the template that applies for Rchan less than the maximum would fail the compliance test.
So, it seems there is some controversy over whether a PSE using the Rchan dependence to adjust the allowed template is allowed or not. Assuming that this means IPort_2P would entering the region discussed above (the “red square”) , it appears we have uncovered an ambiguity in the compliance test, if not the standard. Right now, the standard, as drafted, allows the “red square” in the template.
Did I miss something?
-george
From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Sunday, January 08, 2017 8:58 AM
To:
STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Hi Pete,
Your summary is correct however it is not clear to me why you say “I would agree that any PSE that computes Icon, Ipeak based on any value below maximum Rchan would necessarily fail a conformance test.” ?
As we know currently in the spec Icon and Ipeak are function of Vpse and Rchan so a PSE that use Icon and Ipeak based on Vpse and Rchan is compliant.
ILIM-2P is a fixed number and is designed to be ILIM_2P=2mA+ Ipeak-2P_unb_max.
Yair
From: Peter Johnson [mailto:peter_johnson@xxxxxxxxx]
Sent: Saturday, January 07, 2017 10:45 PM
To:
STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
EXTERNAL EMAIL
George:
Ipeak is both a function of Rchan and Vpse (PSE output voltage).
PSE's with higher output voltage get an "advantage" in supporting lower values for Icon and Ipeak - and that would also extend to Ipeak_2P_unb. Ilim_min, however, is not dependent on Vpse. So tuning Ipeak or Ipeak_2P_unb to Ilim_min gives away that advantage.
Testing PSE's for their sourcing capacity as a function of output voltage is not such a big deal. I would agree that any PSE that computes Icon, Ipeak based on any value below maximum Rchan would necessarily fail a conformance test.
Regards,
Pete Johnson
Sifos
-------- Original Message --------
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, January 06, 2017 6:59 pm
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxxDavid – everyone may have figured it out, but if they did, as you say, here’s the rub -
If, in fact, everyone has figured out to avoid the red box, then, that is defacto the template – might as well make it the template.
However, if someone decides to use the extra room, and invade the red box based on the channel, then, the individual evaluating compliance needs to test at multiple Rchan values to check compliance. Not so good.
If that use of Rchan is only something we might WANT to allow in the future, we can spec it for the appropriate devices. Don’t burden every device fail with a full set of second tests.
I’m not trying to preclude the capability – just don’t want an untestable spec, or to create (any more) questions of compliance or not.
-george
From: Abramson, David [mailto:david.abramson@xxxxxx]
Sent: Friday, January 06, 2017 1:51 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Hi George, Heath, and Lennart,
I have to agree with Lennart here. If you look at the existing standard (I will use 2012 because that what I have lying around), Ipeak is defined as:
Which not only depends on the channel but VPSE as well. While I understand your concern about it being related to the channel (really hard for the PSE to figure out), I would point out that most PSEs just assume a worst case value (lowest value allowed) for VPSE as well. And just for reference, here is the lower bound template for 2012:
And while yes, the lower bound template relies on this parameter, you don’t actually need to do anything with it. Using the same picture I used in my last email:
I would point out that the PSEs just needs to include the red box as part of the lower bound template (use the top of the red box). This removes any relation to the channel from the lower bound template. I don’t see why we would need to change this as I believe everyone has figured this out already.
Regards,
David Abramson
IC Design
Power Interface
Texas Instruments
Office: 603.222.8519
Mobile: 603.410.7884
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, January 06, 2017 11:44 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Lennart – just because the template depended on Rchan in the past doesn’t make it good practice – we’ve uncovered more than a few ambiguities that we’ve dealt with in the new spec.
If dependency on the template is essential and adds a substantial benefit (and is actually used in legacy products or necessary for broad market potential of new products), that’s another story. It comes with a not-insignificant testing cost if one really wants to be compliant.
Testing compliance of the template when the template lower bound varies with Rchan requires testing over various values of Rchan. This is why I was saying that the template should not depend on Rchan. (unless it provides a substantial benefit actually used in legacy products or necessary for BMP of new products)
From: Yseboodt, Lennart [mailto:lennart.yseboodt@xxxxxxxxxxx]
Sent: Thursday, January 05, 2017 11:14 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Hi Heath,
IPeak-2P indeed depends on Rchan, in 2 ways.
First in Eq 33-10, IPeak depends on Rchan.
Second, KIPeak in Eq 33-12 also depends on Rchan.
Because this is so complex (and useless to optimize for), a 'simple' worst-case calculation is provided in the form of IPeak-2P-unb_max. This number is higher than IPeak-2P-unb and using this would automatically mean meeting peak unbalance requirements.
With regard to George's comment that the lowerbound template should not depend on Rchan... that has always been the case, since at least AT.
ICon also depends on Rchan for instance. Here it does make sense as it allows a PSE to optimize the power output to match with the channel losses.
Kind regards,
Lennart
From: Heath Stewart <00000855853231d4-dmarc-request@xxxxxxxx>
Sent: Friday, January 6, 2017 0:13
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
All,
We are noticing a few incongruities after looking at this longer.
1) Inadvertent change
"Alternatively, an over-margined value of IPeak-2P-unb, IPeak-2P-unb_max which is defined by Equation (33–14), may be used."
is incorrect. It creates an alternate definition of IPeak-2P-unb.
It used to create a new variable, IPeak-2P-unb_max, which happens to have a relationship to IPeak-2P-unb. We need to preserve the original wording. This term is only used to form Iunb.
"The worst case value of IPeak-2P-unb is IPeak-2P-unb_max which is defined by Equation (33–14)."
2) The lower-bound template as defined by IPeak-2P (by way of IPeak-2P_unb) now has a third dimension, Rchan-2P. This is not only strange but is at odds with the definition of Icon-2P_unb, which is a scalar.
Is this what we want?
Cheers,
-Heath
On Wed, Jan 4, 2017 at 1:30 PM, Abramson, David <david.abramson@xxxxxx> wrote:
Hi everyone,
I just wanted to give everyone a chance to review my rewrite of 33.2.8.5. I have attached a final version and a marked up version to this email. I have tried to include everyone else’s comments on this section.
Regards,
David Abramson
IC Design
Power Interface
Texas Instruments
Office: 603.222.8519
Mobile: 603.410.7884
