[802.3af] RE: Startup and PD input cap
- To: "'Lynch, Brian'" <brian_lynch@xxxxxx>, "'Dave Dwelley'" <ddwelley@xxxxxxxxxx>, Yair Darshan <YairD@xxxxxxxxxxxxxx>, "'Karl Nakamura'" <karln@xxxxxxxxx>, "'Donald S. Stewart'" <dsstewart@xxxxxxxxx>, "'R karam'" <rkaram@xxxxxxxxx>, "'Rick Brooks'" <ribrooks@xxxxxxxxxxxxxxxxxx>, "'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: [802.3af] RE: Startup and PD input cap
- From: Yair Darshan <YairD@xxxxxxxxxxxxxx>
- Date: Sat, 16 Jun 2001 03:06:01 +0200
- Cc: "'stds-802-3-pwrviamdi@xxxxxxxx'" <stds-802-3-pwrviamdi@xxxxxxxx>
- Sender: owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx
Brian and all.
(This time it is Brian..)
1. I agree that as volume goes up and as the time goes by costs will be
reduced.
2. The questions are:
2.1 Do we need inrush current limit in the PD
Answer:
Depends on PD input cap size. From calculations that you already saw,
up to about 600uF the PSE can handled it . Above this number the
PD should handle it. I am suggesting that the number will be 350uF
to have margin.
2.2 Does the PD is Hot swappable device?
Answer:
No. When the PD is connected to the port, the port voltage is zero!
therefore hotswap issue is not relevant to the PD.
2.3 Does inrush current limit in the PD solves all system problems?
Answer:
No it doesn't solve all system problem it is only solve the inrush
current due to charging the PD input cap.
We still need to solve:
a- Current limit protection in case of short cable or faulty PD etc.
b- Current transients during normal operating mode caused by PSE
output voltage changes that cause to CdV/dT. Somebody needs to limit this
current that can
high as 1-3 ampere peak for 50-100mSec and more.
The inrush current limit in the PD cant do it since it is ON.
We need the PSE to limit it.
c- Current transients at low frequency due to load changes. same
arguments as (b)
2.4 Does inrush current limit in the PSE solves all the system problems?
Answer:
Yes according to two years research and field experiments. The same
circuit answers to a,b,c and in addition we don't have heat problem
according
to the latest calculations.
We are talking about 50mSec duration out of 1 sec minimum period which
is 5% max. duty cycle. No heat problems can raise from this situations.
We have tested chip samples that proves it.
2.5 Are the PD's that using external power source (not Power over MDI
technology) use inrush current limit in the PD?
Answer:
No. At least the 10-15 vendors that we have checked... and they are
right. They don't need it since it works reliably without the problems
raised by Dave.
It is simple straight forward design.
If they didn't use it, why we need it now? what have been changed? the
only difference was that they have in terms of transient current,
un limited source and now we need to limit the source. Isn't it that
the current limiting approach in the PSE is the closest implementation
to the real thing which is unlimited source? How inrush current
limiting in the PD can help us with that matter?
In addition see my comments below.
Yair.
> -----Original Message-----
> From: Lynch, Brian [SMTP:brian_lynch@xxxxxx]
> Sent: ε, ιεπι 15, 2001 7:43 PM
> To: 'Dave Dwelley'; Yair Darshan; 'Karl Nakamura'; 'Donald S. Stewart';
> 'R karam'; '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: Startup and PD input cap
>
> Dave, Roger, and all,
>
> Thanks for bringing up the PD vs. PSE inrush issue.
> (At least it wasn't me this time!)
>
> I agree that in the long term, the cost difference
> between the two approaches will approach zero.
>
> With that issue aside, putting inrush limiting in the PD gives
> us a more robust specification,
[Yair Darshan] Does any body can prove this statement by lab
results and field feedback. We must rely on solid database here and we have
well proven data
that :
PD manufacturers have designed PD power supply input circuit without
inrush current limiting with out any problems.
Inrush current limit in the PSE support those PD's without any
problems.
The spec. for each side is easy to define.
> and far less chance for
> interoperability issues in the future.
[Yair Darshan]
Please specify what kind of interoperate problems you refer to.
Old spec for PD's prior to Power Over MDI technology was: (Example)
: You have 48V, 0.35A continuous max. 1A peak for 100mSec non repetitive
New spec for PD's (802.3af) will say: (Example): You have 48V, 0.35A
continuous 0.4-0.45A peak max. for 50mSec non repetitive.
Now, what is the big difference for the potential PD designer?
Now specify that the PD must contain inrush current limit and
compare the spec required to ensure interoperate between PD's and PSE.... I
can tell you that one of many impacts will be 10-15 people working only for
technical support to answer the following questions:
- How to accommodate with the timing of the isolating switch?
- What will happen if I want to set the inrush current limit to
100mA and my working current is 250mA, how to handle timing?
- Port number 2 was turn off, but port 7 went off too..what I
should do? (put inrush current limit in the PSE was the right answer...)
- I hooked the PD to the port and the PD was turn on successfully
but when I disconnect it and reconnect it was dead (answer the inrush
current limit in the PD wasn't finish to reset .... (obviously with careful
design it can be prevented but you need to be system designer in addition to
PD designer)
-
-
- And many many more.
Bottom line the PD should be designed as it was yesterday. let the
system weight to be on the PSE (especially when you have the functions
required any way)
Bottom line: We need good spec for the system and than design the
hardware and chips according to system needs and not vise versa.
>
> Either method will work. Yair has shown that. The question arises
> whether 5 years from now, with all the "conditions" placed on
> the designs, whether inrush limiting in the PSE will be robust.
[Yair Darshan] Why to wait 5 years. I can have lots of data of the
last two years that shows that it is robust and reliable.
> With PD inrush limiting We know the answer will be yes.
[Yair Darshan] We don't know. Do we have PSE vendors that checked
their PSE with PD's that contains inrush current limiter? on the field? with
many PD vendors?
If yes, I'll be more than happy to get those results.
> Roger, since you are impartial, how about taking a poll as Don has done?
[Yair Darshan] Brian, I would like to believe that most of us are
driving for the best spec. and we are not partial for a solution that is
good for the short run.
Until now I have heard of problems that
people have raised not because they have built the whole system and found
problems.
In our case we have build and test for long
time both concepts and the concept of putting the inrush in the PSE (up to
470uF max. in PD),
found to be the best. Not theory. It is
real.
>
>
> Brian
>
> >-----Original Message-----
> >From: Dave Dwelley [mailto:ddwelley@xxxxxxxxxx]
> >Sent: Friday, June 15, 2001 12:23 PM
> >To: Yair Darshan; 'Karl Nakamura'; 'Donald S. Stewart'; 'R
> >karam'; '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: Startup and PD input cap
> >
> >
> >Yair -
> >
> >Your numbers look good. I've been off-line for awhile, but I'm
> >back now, at
> >least briefly. Here's how I see it (technical first, political second):
> >
> >The 1J number is pretty rough - it's taken off the SOA curves
> >from a couple
> >of typical, SO8 package FETs.* It does seem to be about right
> >(or even a
> >little conservative) for the type of packages that a PSE chip might be
> >packaged in. Since we removed the requirement that multiple
> >ports power up
> >simultaneously at St. Louis, you're correct in saying that the
> >"N" number
> >in your equation is 1, not 8. My old 50uF number (actually
> >77uF) was based
> >on N=8 - no longer necessary.
> >
> >Energy in the cap = 0.5*C*V^2
> >
> >-or-
> >
> >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 second,
> >leaving lots of time for detection and classification. Note
> >also that we're
> >not spec'ing ramp time to 57V (in the worst case) - only to
> >44V. If max I
> >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 worst case:
> >
> >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 tolerance
> >of a typical 470u cap?
> >
> >* Note that I've seen several SOA curves which appear to be VERY
> >conservative, based on a single time constant model. They
> >suggest that the
> >FET is a constant power device below 100ms, not a constant
> >energy device. I
> >don't believe them.
> >
> >Now I'm going to take off my technical hat and put on my
> >system design hat...
> >
> >I still think it's a mistake to allow unlimited-inrush PDs! There are
> >several complications that such devices bring up, like memory
> >in the PD
> >UVLO circuit, long short circuit timeouts in the PSE, possible
> >large dv/dt
> >on the wire when the PD UVLO comes on, and very large peak
> >currents at the
> >PD end of the wire (and the PD end RJ45 jack) when the PD UVLO
> >comes on
> >(before the PSE current limit circuit kicks in). I agree that
> >the circuity
> >in the phone is cheaper this way (slightly, and even less down
> >the road),
> >but I think the corresponding drawbacks make the spec weaker,
> >and invite
> >creative interpretation by marginal PD vendors that will cause
> >interoperability problems and may hinder widespread acceptance
> >of the spec.
> >
> >If we mandate inrush control in the PD in all cases, nearly
> >every one of
> >the above problems goes away, and interoperability is
> >virtually assured (at
> >least with regards to power!). There is additional cost in the
> >PD, but it
> >isn't much... and it the incremental cost will only drop. It's
> >the right
> >thing to do - even though it now has no impact on my ability
> >to integrate a
> >PSE chip.
> >
> >This is the last time I'm going to plead for this - if the
> >consensus is
> >that the cost savings in the PD is worth the hassle of PSE
> >inrush, I'll get
> >on the bus.
> >
> >Dave
> >
> >
> >
> >
> >
> >
> >
> >At 10:13 PM 6/14/2001 +0200, Yair Darshan wrote:
> >>Guys
> >>
> >>I would like to have your comments for the following summary of the
> >>calculation procedure for setting the max. PD input cap to be
> >handled by the
> >>PSE.
> >>
> >>
> >>Target: To make it possible to define more
> >than 50uF as the
> >>point in which the responsibility for inrush current limiting
> >is moved from
> >>the PSE to the PD.
> >>Incentive: 1. Low cost PD power supply
> >implementations works at
> >>100KHZ. for 10-12W power supply, max. 470uF is needed. for 5W
> >power supply
> >>220uF-270uF
> >> is needed.
> >> Caps lower that 50uF requires
> >high frequency
> >>switching power supply (around 500KHZ) which costs much more.
> >>
> >> 1.1 50-60% of the applications are
> >5-8Watts. 30-35%
> >>are 10-12Watts. It means that around 95% of the applications
> >will need 220uF
> >>to 470uF.
> >> (Data based on PD power
> >requirement survey done
> >>during the last 6 month)
> >>
> >> 2. In order to meets system
> >stability criteria as
> >>discussed over the reflector during the last 3 weeks, we need
> >to keep low
> >>L/C ratio at the PD power
> >> supply input. Stability criteria
> >requires that
> >>L/(ESR*C)<< Zin, L inductance, C=Capacitance of the
> >> EMI filter, ESR is the equivalent series
> >>resistance of the Cap.(There are additional stability
> >criteria, however this
> >>one concerns the EMI filter
> >> connected to negative resistance
> >network) It
> >>means that we need to allow low inductance for a given Cap
> >size or Large cap
> >>for a
> >> given inductor size. In order to
> >implement the
> >>EMI filter we need the inductor to have 10-500uH (pending on topology,
> >>switching frequency and EMI
> >> requirements) therefor we need
> >Larger Caps.
> >> Although (2) can be achieved when
> >the inrush current
> >>limiting is in the PD, It will be cost effective to the
> >system to allow
> >>larger cap in the PD allowing
> >> the PSE to be responsible to
> >limit the inrush
> >>current pending that it will allow the integrated chip in the PSE.
> >>
> >>
> >>Vport= Port voltage
> >>Iport = Port current limit level
> >>N= Number of active ports per device(active port=at startup mode).
> >>Tc= The time that the port is in current limit situation =
> >The PD capacitor
> >>charging time.
> >>Emax= Max energy aloud on the device.
> >>
> >>1. Assuming Emax=0.5*N*Vport*Iport*Tc, Energy dissipated on
> >the device
> >>during startup mode
> >>
> >>For the following max. values:
> >>Vport=57V max.
> >>Ip=0.5A max
> >>Emax=1Joule (as per Dave data)
> >>
> >>Assuming that in 8 port device only one port is performing
> >the startup mode
> >>(we can control the timing) and there is a cooling time until
> >the 2nd port
> >>will be in startup mode.
> >>N=1. (Remember that it is non repetitive operation.)
> >>
> >>2. Tc max = Emax/(0.5*N*Vport*Iport) =
> >1Joule/(0.5x1*57V*0.5A)=70.16mSec
> >>
> >>3. Ip*Tc=Cin*Vp
> >>
> >>4. Cin max=Ip*Tc/Vp=0.5A*70.16mSec/57V = 615uF
> >>
> >> >From eq. 4 we can have 615uF instead of 50uF.
> >>
> >>Since the above numbers are worst case calculation, we have
> >the following
> >>margin:
> >>
> >>The PSE can be set to 0.4A min. (The calculation in eq-2
> >was for 0.5A)
> >>Tc max can be set to 50mSecmin (The result of eq-2 was 70.16mS)
> >>
> >>According to the above margin Cin max would be: Cin
> >>max=0.4A*50mSec/57V=350uF
> >>
> >>Therfore we have 615uF/350uF ==> 75% margin.
> >>
> >>In addition, the above calculations assumes repetitive
> >operation which is
> >>not the case for startup, hence much larger margin, with no
> >effect on power
> >>supply loss, cable loss etc.
> >>
> >>We can utilize the numbers that we have used for the normal
> >powering mode
> >>and use them as a private case for the startup mode:
> >>
> >>During startup, the PSE will limit its output current to:
> >>1. Ip min=0.4 Ipmax=0.5
> >>2. Time duration: 50mSec min. 70mSec max.
> >>3. Period: 1 sec min. ( To allow low average power in
> >order to have
> >>enough cooling time. It is similar to the timings of the
> >normal operating
> >>mode)
> >>
> >>PD spec.
> >>Under the above numbers the PD will be specified as follows.
> >>1. Up to 350uF at PD input, PD designer have the
> >following resources:
> >>2. Ip=0.4A min for 50mSec min.
> >>
> >>For caps greater than 350uF, the PD designer will take care
> >of limiting the
> >>inrush current to be 0.4A max (i.e. < 0.4A)
> >>
> >>
> >>Comments
> >>
> >>Thanks
> >>
> >>Yair.
> >>
> >>
> >>
> >>
> >>Darshan Yair
> >>Chief Engineer
> >> > PowerDsine Ltd. - Powering Converged Networks
> >> > 1 Hanagar St., P.O. Box 7220
> >> > Neve Ne'eman Industrial Zone
> >> > Hod Hasharon 45421, Israel
> >>Tel: +972-9-775-5100, Cell: +972-54-893019
> >>Fax: +972-9-775-5111
> >> > E-mail: <mailto:yaird@xxxxxxxxxxxxxx>.
> >> > http://www.powerdsine.com
> >> >
> >> >
> >> >
> >