| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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. Regards Yair From: Ken [mailto:ken_bennett@xxxxxxxxx]
Hi All, 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: ---- 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. ----- Yair: Absolutely correct.
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.
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. --------------------- 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, Yair: Agree. ---- 2) PSE's: it may be more appropriate to specify a Voltage unbalance at specified currents Yair: Agree.
Yair: -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. --------
On 5/1/2014 8:23 AM, Darshan, Yair wrote:
|