RE: [802.3af] Re: Startup and PD input cap
- To: "'R karam'" <rkaram@xxxxxxxxx>, Dave Dwelley <ddwelley@xxxxxxxxxx>, Yair Darshan <YairD@xxxxxxxxxxxxxx>, "'Karl Nakamura'" <karln@xxxxxxxxx>, "'Donald S. Stewart'" <dsstewart@xxxxxxxxx>, "'Rick Brooks'" <ribrooks@xxxxxxxxxxxxxxxxxx>, "'Lynch, Brian'" <brian_lynch@xxxxxx>, "'Peter Schwartz'" <Peter.Schwartz@xxxxxxxxxx>, "'scott_burton@xxxxxxxxx'" <scott_burton@xxxxxxxxx>, "'Steve Carlson'" <scarlson@xxxxxxxxxxxxx>, "'rk@xxxxxxxxxxxxxxx'" <rk@xxxxxxxxxxxxxxx>, "'mike_s_mccormack@xxxxxxxxxxx'" <mike_s_mccormack@xxxxxxxxxxx>, "'bruce.inn@xxxxxxxxxx'" <bruce.inn@xxxxxxxxxx>, "'henryhinrichs@xxxxxxxxxxxx'" <henryhinrichs@xxxxxxxxxxxx>, "'Jetzt, John J'" <jetzt@xxxxxxxxx>
- Subject: RE: [802.3af] Re: Startup and PD input cap
- From: Yair Darshan <YairD@xxxxxxxxxxxxxx>
- Date: Fri, 15 Jun 2001 21:03:43 +0200
- Cc: "'stds-802-3-pwrviamdi@xxxxxxxx'" <stds-802-3-pwrviamdi@xxxxxxxx>
- Sender: owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx
Roger and all,
We already agreed that PSE will have inrush current limiter up to 50uF in
the PD. Now as we agreed at St Louis, I have optimized that number to get
I have answered Dave's concerns in my previous email. ( 2 minutes ago..)
I agree that high volume will reduce the cost.
And I agree that what is most important is system reliability.
From system reliability point of view, we must have the inrush current
limiter also in the PSE. (Please refer to my answers below to Dave.)
Question to all PD designers. Today in your PD's that are using external
power source, do you have inrush current limiter in the PD's ? Probably not.
So why we need it now? To protect PSE port? the answer is yes. We need to
protect PSE port any way (for shorts in cable, in PD input etc. ) So use the
current limit protection to also limit the inrush current with the same
cost. (We already show that there is no thermal problem). It is as simple as
And last the beauty in it that it is working and we don't need to invent the
p.s see below more info.
Your numbers look good. I've been off-line for awhile, but I'm back
Energy in the cap = 0.5*C*V^2
Max cap for 1J = 2/V^2 = 2/57^2 = 615uF, same as Yair's number.
It's pretty clear that we can ramp this cap up in well under a
leaving lots of time for detection and classification. Note also
not spec'ing ramp time to 57V (in the worst case) - only to 44V. If
is 400mA and C=470u+20%, then:
ramp up time = C*V/I = 564u*44/0.4 = 62ms
Total energy (this time to 57V, which is what the FET could see
energy = 0.5*564u*57^2 = 0.92J, under 1J (barely).
470u + 20% is OK from a thermal point of view if N=1. What is the
of a typical 470u cap?
[Yair Darshan] Around 10-20% for low cost solutions.
* Note that I've seen several SOA curves which appear to be VERY
conservative, based on a single time constant model. They suggest
FET is a constant power device below 100ms, not a constant energy
don't believe them.
Now I'm going to take off my technical hat and put on my system
I still think it's a mistake to allow unlimited-inrush PDs!
[Yair Darshan] Brian: all PD's that I have checked that are using
other power source are not contain inrush current limiter since technically
it is not required since
the current which is equal to C*dV/dT is easily handled by the input
cap and the wiring connection. It is vanished within microseconds if the
source is a low impedance one and several tenth of ms if the source is
limited. (See as an example HDSL modules which are remote feeding units and
the remote unit (which is the PD in our case) works fine with out any
Usually inrush current limiters are used in devices that are usually
hot swapped or are connected to high input voltage such as mains (110V,
Our PD is not belong to any of these families of products.
several complications that such devices bring up, like memory in the
[Yair Darshan] Memory problem can be in the PD if you have inrush
current limit in the PD (pending of how it is implemented) however if you
inrush current limit in the PD but only standard input circuit
(wire, diode, cap, UVLO , DC/DC converter etc. in this order) you should not
have problem it is pretty straight forward design. Can you show example of
such a problem?
[Yair Darshan] You need UVLO in any case.
, long short circuit timeouts in the PSE,
[Yair Darshan] Thermally it can handled as shown in the above
possible large dv/dt
on the wire when the PD UVLO comes on,
[Yair Darshan] How inrush current limit in the PD solve this.
Actually you have big caps in both sides and the impedance is low and the
dV/dT is very slow.
and very large peak currents at the
PD end of the wire (and the PD end RJ45 jack) when the PD UVLO comes
[Yair Darshan] Brian: The normal operating current is 350mA average
max. The peak inrush current during startup is 0.4A, only 50mA difference.
In addition, in normal operating mode we allow repetitive current of
0.4Apeak for 50mSec. Here we are talking on non repetitive current. There
for I don't see where is
the problem. Please advise if I miss something.
(before the PSE current limit circuit kicks in).
[Yair Darshan] Any current limit has limited time response whether
it is in the PSE or in the PD.
I agree that the circuity
in the phone is cheaper this way (slightly, and even less down the
[Yair Darshan] Accurate an real implementations have shown that up
to several hundreds uF in the PD, the system cost is the lowest if inrush
current limit is in the PSE. It is not estimations. It facts. It is based on
real implementations that are checked by chip vendors and by system
designers and most important by the customers. When it comes to putting a
tag price on each options we keep getting the same answers as I state above.
but I think the corresponding drawbacks make the spec weaker, and
creative interpretation by marginal PD vendors that will cause
interoperability problems and may hinder widespread acceptance of
[Yair Darshan] The PD and the PSE will have test set up that will
ensure meeting the spec and prevent inter-operate problems.
(Like we do for any parameter and function.
However the system will be more robust if the inrush current limit
will be in the PSE since it is the closest definition to an unlimited source
compared to other alternatives. This is a major point and we must understand
I, as a system designer, seek for a power source that will supply
the power even if I have current transients through the Line and I don't
want the PSE to shut off under such events since these events are natural
phenomena (Due to PSE voltage changes, Induction, Load changes etc.)
As I have mentioned many times, PD users are looking for the same
quality and reliability from their power source as they where used to get
prior the Power Over MDI technology, and the technology that we are trying
to specify should not be inferior.
If we mandate inrush control in the PD in all cases, nearly every
the above problems goes away,
[Yair Darshan] If we will have inrush current limit in the PD and
we will have current transients due to PSE output changes (at normal
the PSE will shut off !! The only way to prevent it is to use
unlimited power source. since we cant use unlimited power source we need to
use limited power source which is time dependent. And the guy that can do
the job is a PSE output with inrush current limiter that allows transient
current above the normal operating current (0.4A-0.5A) for limited time
How inrush current limiter in the PD can solve this problem?
and interoperability is virtually assured (at
least with regards to power!). There is additional cost in the PD,
isn't much... and it the incremental cost will only drop.
[Yair Darshan] If you have numbers that are based on actual
implementations I would be happy to review them since this is an important
The numbers that I have are showing the opposite and they are based
on real implementations and a lot of data from the field.
It's the right
thing to do - even though it now has no impact on my ability to
This is the last time I'm going to plead for this - if the consensus
that the cost savings in the PD is worth the hassle of PSE inrush,
on the bus.
[Yair Darshan] Please continue to plead for this if I haven't
succeed to convince you. I believe that it is a major issue and I can
support it with a lot of data
and actual and well working implementations
> -----Original Message-----
> From: R karam [SMTP:rkaram@xxxxxxxxx]
> Sent: ?, ???? 15, 2001 6:45 PM
> To: Dave Dwelley; Yair Darshan; 'Karl Nakamura'; 'Donald S. Stewart';
> 'Rick Brooks'; 'Lynch, Brian'; 'Peter Schwartz'; 'scott_burton@xxxxxxxxx';
> 'Steve Carlson'; 'rk@xxxxxxxxxxxxxxx'; 'mike_s_mccormack@xxxxxxxxxxx';
> 'bruce.inn@xxxxxxxxxx'; 'henryhinrichs@xxxxxxxxxxxx'; 'Jetzt, John J'
> Cc: 'stds-802-3-pwrviamdi@xxxxxxxx'
> Subject: Re: [802.3af] Re: Startup and PD input cap
> Hi to all,
> adding my 2c to this.
> let's do what is technically robust and two things will happen here
> quoting Karl Nakamura all along in this standard has been saying:
> " A- we succeed then volume drives cost down
> B- we fail then it really does not matter"
> we paid $17 for a 10/100 phy early in the game (96-97) does anyone care to
> see where it
> is at now? last year it was around $2 or so.
> If we think PD inrush is technically more robust then that should be the
> way, so Far and I am
> not speaking for anyone, it seems like a lot of the analog vendors favor
> it, of course it buys me
> an integrated solution in the switch but we will never let the software
> guy power 4 or 8 ports in
> no time difference so this should no longer be the political potatoe we
> are worried about ....
> if we think there is no potential for problems there will be problems, but
> if we think going in
> that we are taking higher risk, we may create a mess. So i would
> appreciate a vote on how many
> of us agree with Dave that having the inrush in the PD may be worth while
> sorry for dwelling.