| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Anoop, Thanks for the comments. See my response below. Yair From: Hi Yair Some more comments on your presentation: - Rather than having PSE Ilim_min = PD
Ilim_max + 1mA; I think it will be a cleaner solution to increase the Tlim_min
for PSE from 50ms to 51ms (or 55ms to make it a round figure). My third
point will make it clear why I like this approach (This makes energy based
policing easy). Yair: Do you mean to increase Tcut_min or
Tlim_min. To increase Tcut_min in PSE may be also good solution, I need to
check. Tlim_min is not opart of the problem here since we want to gurrantee
that in the worst case when PSE set ILIM=ILIM MIN and PD consume exactly
Icut_max then the net charging current is zero so the Cpd will not be charged
to 7V. So if PSE ILIM_MIN=PD ILIM_MAX+1mA = PSE ICUT_MAX+1mA then problem
solved. If we limit PD ICUT_MAX=PD ILIM_MAX to 50msec
max and PSE ICUT_MAX to Tcut_min=51msec or more (probably more) then after
50msec we will have net charging current >0 so as you say it will solve the
problem too. Regarding what is cleaner solution between
the above too, well, I like the 1st one due to the fact that it
creates gray area between PSE ILIM_MIN to PD_ILIM_MAX AND WE DON’T have
to touch timings that are already set in the silicon for other purposes. Any way, both solutions are OK. ----------------------- -
I do not like the term Ilim_min for PSE. The whole reason why
we have current limiting at PD is so that we do not have to do current limiting
at the PSE. We need to come up with a better name. Yair: You want to change the names for
802.3af too? Or only for 802.3at?.
I like the current names because they are clearly indicates a max. or min
current. I understand your concerns and I suggest to ad in table 33- ---------------------------- - In 802.3af we had Ilim_min/Icut_min =
14.28%. There is no rational reason why we need to keep this ratio the same for
802.3at. We have much more advanced processes today. We need to come up with the minimum PD
Ilim_max that is acceptable to everyone. Yair: The rational for 14% and not 7% is
cost. Accuracy, design margins and chip yield costs. Wide range of a parameter
solve it.
We agree several times during the last 2 years to keep the same ratios of
802.3af in 802.3at.
Regarding
the advanced processes that we have today: in order to allow all kinds of
implementations you have to assume that the worst case implementation in terms
of circuit accuracy is when PSE's ILIM_min and max are at narrow range e.g like
in 802.3af so during the last 5 years processes has not improved by a
factor of 2. Actually if I want to implement linear current source then
processes still requires 14-15% marging range so it will be +/-7-7.5% for each
side to reduce chip cost. So if
vendor A can be satisfied with total 7% and vendor B can use 10% and Vendor C
14% so as you said we have to use margins that are exaptable to every one which
is 14-15%.. We can
not use 7% total margin and guarantee full 29.5W at the PD. It is not
practical. On the other hand to have margin of 14% instead of 7% should be good
to every one.. -------------------- There is also no reason why we need to
specify that there be a maximum duty cycle of 5%. Even if we impose this, it is
highly unlikely that a PSE is going to check for 5% dutycycle over 1s. All we
care is the threshold and average current. Yair:
Regarding the 5% duty cycle: 802.3af chips should impose 5% duty cycle
limitation since it is required by the standard. PSEs that are not meeting this
requirement are not compliant. See 33.2.8.4
and PSE38 in the PICS. Regarding 802.3at: we could leave the
decision of imposing 5% duty cycle limitation to the system and making it optional
the problem might be interoperability. If 802.3at PD that is requesting only 12.95W
and uses ripple current that exceeds overload requirements, will work in 802.3at
(if not imposing 5% duty limitation) and will not work in 802.3af PSE. So for
the sake of interoperability I suggest to use the same 802.3af
definitions. We can discuss it more in the group. ----------------------------- If the PD draws more than Iport_dcmax
(720mA) for more than 51ms (or 55ms) then the PSE can shut off the PD.
There is no averaging involved here. This is a hard threshold as in AF -
Icut/Tcut If the average current
drawn by the PD over 1 second is greater than Iport_dcmax (720mA) then the PSE
can shut off the PD. Yair: This is correct. This arrangement allows
utilizing the max 12.95W in af and 29.5W in 802.3at. If the PD draws 720mA with
sine wave ripple of 100mA pp then the average will be 720mA DC so PSE shall not
disconnect the port while PD current is between 920mA and 620mA ..so you cant
count on the DC value only you need to know the peak current, duration and duty
cycle. This is the reason for how it was specified in 802.3af. I hope that I understand your point here. Yair --------------- Thank you Anoop From:
owner-stds-802-3-poep@ieee.org [mailto:owner-stds-802-3-poep@ieee.org] On Behalf Of Hi Fred, Some comments: Slide 4: Icut_max/Icut_min is
0.4/0.3-1=14.28% and not 7% as stated. Slide 5: I like the simplicity of how PD
is specified in 802.3af then how it presented in slide 5: We should allow
utilizing the full 29.5W as permited by the average current of 0.72A. We can do
it easily by keeping the same concept and margins as in 802.3af. Having 14.28%
margin between Icut_max to Icut_min allows it. It is difficult to understand slide 5. I
disagree with the 1st bullet. We should allow implementations that
uses dc current with ac ripple within the range specified between Icut_max to
Icut_min limited to 50msec max and 5% duty as in 802.3af. Slide 6: The point of having the current
limit at the PD was to solve inrush current due to dv/dt in PSE and dealing
with long TLIM_MIN.
This slide suggests that PD with less then Cpd_max don’t have to
implement current limit. This was exactly the case in 802.3af so what is the
purpose of having all this PD current limit discussion? If Cpd is
179.9UF<180U then Tlim _min may be still 12.6msec and we are back to square
1 = 3month ago.. The solution is what I thought last
meeting: PD will limit the current within 1msec to ICUT_MAX so we will have to
charge only 0.12uF for the rest of the 50msec max of TCUT. See my presentation
that explains the whole thing. Slide 6: This slide is relevant only if PD
limits to Icut_min. which doesn’t support a solution to utilizing max
29.5W. See my presentation for proposal to solve this issue. In addition, please allocate time to
discuss my presentation that may help to solve some issues that was supposed to
be solved by moving the current limit to the PD and in my opinion are still
requires some discussion. The rest looks fine. Yair From: Hello, IEEE 802.3at, Vport ad hoc team meetings are scheduled for
Tuesday June 26, July 3, and July 10 (9 AM, PST) to cover current limits
required for PoE. Please review the direction we are heading at: http://grouper.ieee.org/groups/802/3/at/public/may07/schindler_5_28_07.pdf Please also review: http://grouper.ieee.org/groups/802/3/at/public/may07/avetteth_0507.pdf Please
ensure that you review the IEEE-SA PatCom slides [ http://standards.ieee.org/board/pat/pat-slideset.pdf
] prior to the start of the conference call. At the start of call I will ask
that everybody confirms that they have read this material - if anybody hasn't
we will pause the call until they confirm that they have done so. Thanks, Fred ______________________________________________________________________________ Frederick Schindler has
invited you to a Cisco Unified MeetingPlace Conference Date/Time:
JUN 26, 2007 at 9:00AM Length:
60 Frequency:
3 Meeting ID:
131128329 Meeting Password:
Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html US/Canada:
+1.866.432.9903 United
Kingdom: +44.20.8824.0117 TO ATTEND A WEB AND VOICE
CONFERENCE: CISCO
INTRANET ATTENDEES Join the Web & Voice
Conference* 1. Go to http://meetingplaceinternal.cisco.com/join.asp?131128329 2. Enter your CEC
User ID & Password then click OK - Accept any security warnings you receive and wait
for the Meeting Room to initialize 3. Click on CONNECT
from the Meeting Room to join the Voice Conference portion of the meeting EXTERNAL
ATTENDEES - Outside the Cisco Intranet** Join the Web & Voice
Conference* 1. Go to http://meetingplace.cisco.com/join.asp?131128329 2. Fill in the My
Name is field then click Attend
Meeting - If you have a CEC User ID, click on the Cisco icon - Accept any security warnings you receive and wait
for the Meeting Room to initialize 3. Click on CONNECT
from the Meeting Room to join the Voice Conference portion of the meeting *If
this is your first time attending a Web Conference, disable any pop-up blockers
and visit http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp
to test your web browser for compatibility with the Web Conference. **Not
all meetings are scheduled to allow external attendees into the Web Conference
portion of the meeting, if the URL does not work, please follow the Voice only
Conference instructions below to attend. TO ATTEND A VOICE ONLY
CONFERENCE 1. Dial into Cisco Unified MeetingPlace (view the
Access Numbers and link above) 2. Press 1
to attend the meeting 3. Follow the prompts to enter the Meeting ID 131128329 and join the meeting SUPPORT Information about this
Conference: Contact Frederick
Schindler, 14085259859 Cisco IT GLOBAL
ACCESS NUMBERS COUNTRY
LOCATION
LOCAL
NUMBER
TOLL
FREE-FREEFONE
West
+1.408.525.6800 1.866.432.9903 Argentina Buenos
Aires +54.11.4341.0101 Brazil
Brasilia
+55.613.424.0220
Regina
+1.306.566.6410
Toronto
+1.416.306.7230
Vancouver +1.604.647.2350
Winnipeg
+1.204.336.6610 Chile
Santiago
+56.2.431.4936 Colombia
Bogota
+57.1.325.6065 Mexico
Mexico City +52.55.5267.1800 Peru
Lima
+51.1.215.5101 Puerto Rico San
Juan
+1.787.620.1865 Venezuela
Caracas
+58.212.902.0210 EMEA
Austria
Vienna
+43.12.4030.6022 Belgium
Diegem
+32.2.704.5072 Bulgaria
Sofia
+359.2.937.5938 Croatia
Zagreb
+385.1.462.8908 Denmark
Aabyhoj
+45.8.939.7131
Copenhagen +45.3.958.5010
Hallbergmoos +49.811.554.3016 Norway
Oslo
+47.23.27.3647 Poland
Warsaw
+48.22.572.2615 Portugal Lisbon
+351.21.446.8756 Slovakia
Bratislava +421.2.5825.5309 South
Africa
Johannesburg +27.11.267.1011
Pretoria
+27.12.844.7401
United Arab Emirates
(UAE)
HongKong
HongKong
+852.3414.1802
Wellington
+64.4.496.5554 Phillipines Makati
(Manila) +63.2.750.5886 Singapore Singapore
Capital +65.6317.7088
Ho Chi Minh City +84.8.823.3418
(Saigon)
Technical Leader CISCO Systems M/S SJ-19-3 Tel. (408) 525-9859 |