| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Martin. See my comments below. Thanks for the inputs. Yair From: One of the fundamental problems with .af is that
there were a number of ways that non-compliant PDs (or non-PDs) could fool the
2-point detection schemes. Yair: Yes it is true. The classification in 802.3af was not mandatory
at the PSE and this is the source of the problem that I am trying to make. If PSE classification was mandatory in 802.3af
then it was OK to go to Idle in any case that you have any kind of class_error
condition because you had to assume the the PD is defective or non compliant. ---- It would seem unlikely that a real PD would be
trying to draw Iclass_lim. However, a non-PD that fooled detection and
tried to dram Iclas_lim should be rejected. Yair: Yes this is true but it is possible the PD is equipped
with defective classification circuit and still will get power due to the fact
that he pass detection and he is truly PD and not dumb PD. The chances are low
but it is possible. ---- Basically, numerous solutions have found it easy
enough to meet the PD requirements for Iclass. And we should protect the
future of a possible Class 5. Yair: I don’t believe that in the future
we will use class 5 by increasing the current. This road was examined by
802.3at and was rejected due to thermal issues. The way we agree to increase the number of
classes in the future is using the coding options inherent in two fingers
operation. That's why we agree last meetings to go to IDLE
if the results of the two fingers are not 4:4: so in the future we can use the
options 4;1, 4:2 and 4:3 which are at least 3 more class numbers. ----------------- I don't see an issue with a change in the PSE
behavior between type 1 and type 2. The type 1 behavior was an attempt to
dictate what a PSE did under an error condition. It was not a
back-door PD specification. That is, a PD that draws Iclass_max
during classification does not meet the standard (is
non-compliant). There is no expectation that a non-compliant PD
must be powered. I vote for the "go to idle" when the PD
draws Iclass_max. Regards, Martin
From: We only have to guarantee interoperability for
compliant devices. A device that draw more than 51mA during classification
is noncompliant. As I pointed out in my comment it was a mistake
in AF to allow a PSE to power a device that has failed classification and that
we should fix that in AT. I'm not concerned that a device that is
noncompliant will not get power from a Type 2 PSE. The other problem with your remedy is that there
is a two layer slight of hand going on here. If you allow a Type 2 PSE to
assign this noncompliant PD class 0 there is another statement that says the
Type 2 PSE can treat the class 0 PD as Class 4 and now we are back to the
start. You are allowing a noncompliant device to draw up to 30W,
therefore enabling dumb PDs. My opinion is this is completely
unacceptable. If I were a devious designer, I would just draw 60mA during
class and then move on to drawing 30W. the only thing we have to be careful of is that
we are not making all legacy PSEs noncompliant by removing their ability to
power devices that fail classification as Class 0. I would support your
statement if it said: If
a PSE detects Iclass_lim, it may power the PD strictly at Class 0 levels
or it may choose to enter the IDLE mode. A Type 2 PSE that decides to
power a PD that violates Iclass_lim shall limit Pport to 15.4W. In this
case, there is no allowance for the Type 2 PSE to power at Type 2 levels. or some other equivalent but better
wording. I would want a shall statement that generates a PICS that would
check that a PSE will police at 15.4W if it powers a noncompliant device.
Of course we would also have to figure out how to work this into the state
diagram. To me the easier solution is to make the decision
to not power these devices. - From: Hi
guys, I
have found a problem with the remedy on the above subject. We
have 3 cases in which we agree last meeting to return to IDLE state. Case
1: If
PSE type 2 reads class The
rational was that we don’t want to encourage someone using different
coding so we can reserve it for future use. So
far it makes sense. Case
2: If
PSE Type 2 pass detection successfully and fails to complete classification, it
will return to IDLE state. Rational: Classification
in Type 2 PSE and PD is mandatory. If it is not working then probably one of
the two parts PSE or PD is non compliant or defective. Case
3: If
PSE detects Iclass_lim, it will return to IDLE. The
problem is in Case 3. Rational: a)
If PSE type 2 connected to PD type 1, and PSE reads Iclass_lim then according
to last week change, PSE will return to IDLE state. b)
But If PSE type 1 connected to PD type 1, and PSE reads Iclass_lim, PSE is
assign Class 0 which mean the PD will be operated. Which
means that in (a), PD type 1 will not work ever never with PSE type 2 under
Iclass_lim and may work with PSE type 1. This
is violates backwards compatibility and creates interoperability problems
between PSE type 1 and PSE type 2 connected to PD type 1 exhibiting Iclass_lim. The
solution for this problem is: In
Case 3 (and maybe also in case 2) , The PSE type 2 shall assign Class 0 as well
as Type 1 PSE, if it detects Iclass_lim. What
is your opinion on these guys? Yair
Analog Mixed Signal Group Microsemi Corporation
Cell: +972-54-4893019 E-mail: <mailto:ydarshan@microsemi.com>. |