|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi George and Heath,
I will try to address each point you guys made.
First, George, you are completely correct about the reference in Table 33-18, item 22 to the term Ipeak-2p-unb-max. I did not catch that and thus my rewording of that sentence now seems strange. My understanding when I rewrote this section was that this was the worst case value which people could use in order to simplify the math. I used Pclass as an example, here is how Pclass which has a complex equation and simple values in the table is worded (taken from page 110):
The minimum power output a PSE supports for a particular PD Class, when powering a single-signature PD, or supplying power in 2-pair mode, is defined by Equation (33–2). PSE implementations may use VPSE = VPort_PSE-2P min and RChan = RCh when powering using a single pairset, or RChan = RCh/2 when powering using two pairsets to arrive at over-margined values as shown in Table 33–13.
Thus, not realizing that Ipeak-2p-unb-max was used anywhere else, I assume it was a similar thing. Now, I still believe the “over margined, but simpler” approach that uses Ipeak-2p-unb will still be used in that way. This would mean people actually implement a lower bound template with the red square included as beneath the template:
I believe this is what most people do currently anyways. As such, I would like to try to come up with some wording that gets that point across while also referencing the use of Ipeak-2p-unb-max in the Iunb requirements. I am sure we can do that over a beer.
For Heath’s second point, I am not sure what to say as I did not change any of the technical requirements (the lower bound template already depended on Rchan(-2P) before my rewrite. However, I will give my opinion in a second email since there has been further discussion since this email.
I emailed David A about the ‘Alternatively’ issue on item 1 above (hadn’t heard back). I agree with you it is a problem.
Because IPeak-2P_unb_max is actually used in a requirement which references 220.127.116.11 – Table 33-18, item 22 (page 121), this is problematic. Additionally, the term, “may be used.” Is difficult – “may” gets translated to “is permitted to be” in IEEE standards language - may be used for what? – it doesn’t say.
We could change Table 33-18 item 22 as well, and create a new value, AND change the language here, I suggest a different, smaller change, that I think preserves the improved clarity that David was trying to bring, AND avoids the problem:
I would delete “Alternatively” and replace “may be used” by “is used in Table 33-18 to limit the unbalance current in Type 3 and 4 PSEs.”
So that it says:
"An over-margined value of IPeak-2P-unb, IPeak-2P-unb_max which is defined by Equation (33–14) is used in Table 33-18 to limit the unbalance current in Type 3 and 4 PSEs."
2) I also agree that the lower bound template should be independent of the channel. I don’t have a good fix for that right now.
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?
On Wed, Jan 4, 2017 at 1:30 PM, Abramson, David <david.abramson@xxxxxx> wrote: