I like your
summary and I propose that you make a presentation out of it
for the IEEE meeting.
It covers many
below in lines, my response to the points you have raised.
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.
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
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:
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
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
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
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..
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.
-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.
On 5/1/2014 8:23 AM, Darshan, Yair wrote:
Attached please find the meeting material
for today in addition to what was send already today. Total
802.3bt End to End Channel P2P Resistance
Unbalance ad hocAd hoc chair.
over HDBaseT Subcommittee
Mixed Signal Group
Hanagar St., P.O. Box 7220
Ne'eman Industrial Zone
Hod Hasharon 45421, Israel