[802.3af] quick questions
Yair -
I'm answering Brian's mail again - sorry!
Before I try to address the points you raised in your previous notes, let
me ask a couple of questions -
1. Do the non-inrush PDs that are in the field now (in your 2.5, below)
have a UVLO in front of the large cap? If they do, does the UVLO turn on
quickly, or does it have gradual hot-swap-like behavior?
2. I don't understand your 2.3, below - why won't the PD inrush work for
line transients? I'm proposing a current limit at both ends, with the PSE
set higher than the PD, like Rick discussed at Hilton Head. If the PD
current limit (which is also the inrush limiter) is always active, there is
no disconnect problem when the PSE voltage steps UP - the PD will limit
current to 350mA and all is well. If the PSE voltage steps DOWN, both
schemes are in trouble if there is a diode anywhere in series - it doesn't
matter where the current limit is located in this case!
The only way to beat this step-down problem is to have a long disconnect
timeout (dangerous if the timeout is slower than a fast technician), or to
force the PD to somehow draw >10mA even if the line steps down - more
circuitry. BTW, we still haven't addressed this (unless I was asleep for
that part of the meeting). Do we have a scheme to fix this problem?
Your 350uF number is fine for dissipation at turn-on, and it's marginal but
probably OK (57V*400mA*50ms=1.14J) for the short circuit case if the limit
is in the PSE. Note that the short circuit case is twice as bad as the
inrush case, since the voltage does not decrease with time like it does in
the turn-on case.
Yair, we've answered all the IC-related technical issues - LTC or any other
vendor can build an IC that works fine thermally with 350uF and PSE-only
limiting. My concern now is only spec based - I'm worried that someone can
build a non-inrush controlled phone that meets the spec as it now stands,
yet could cause high dv/dt at turn-on or large transient currents,
primarily due to the UVLO ahead of the big cap turning on too fast.
Dave
At 03:06 AM 6/16/2001 +0200, Yair Darshan wrote:
>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
> > >> >
> > >> >
> > >> >
> > >
*****LINEAR TECHNOLOGY CORPORATION*****
*****Internet Email Confidentiality Footer*****
This e-mail transmission, and any documents, files or previous e-mail
messages attached to it may contain confidential information that is legally
privileged. If you are not the intended recipient, or a person responsible
for delivering it to the intended recipient, you are hereby notified that
any disclosure, copying, distribution or use of any of the information
contained in or attached to this transmission is STRICTLY PROHIBITED. If you
have received this transmission in error, please immediately notify me by
reply e-mail, or by telephone at (408) 432-1900, extension 2593 and destroy
the original transmission and its attachments without reading or saving in
any manner. Thank you.