|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
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?
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.
On 5/1/2014 8:23 AM, Darshan, Yair wrote: