| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>. |