Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Fred, I have few
comments/questions: Slide 17: I understand
that you got good results with OCL=120uH at the transmitter side. What was the
OCL in the receiver side? (Ignore for the moment the fact that the receiver has
no requirement to meet any OCL value). The reason for the
question is that the receiver OCL affects the equivalent transmitter OCL i.e. if
Transmitter OCL is 120u and reciver OCL is at least 350uH than the effective
OCL in the system channel is 120u*350u/470u = 89u and if both sides OCL
is 120u than the effective OCL in the channel is 60uH which is 30% lower. If
under this worst case condition you got good results then we are good on this
aspect of the discussion. Slide 17 on the bottom,
note 1: the 2nd line meaning is not clear to me. Do you mean that
OCL is developed below 320u? please clarify. Slide 18: This conclusion
is also confirmed when you check in the frequency domain. The gain and phase
has little changes if OCL changes from 350u to 150u from 100KHz and up. We
discuss it in the past and confirmed again after the frequency domain model was
checked for large signal as well. By the way I can check with this model the
effect of OCL=120U in both sides PSE and PD and then recheck when Midspan is
inserted. Slide 21: Regarding the
question if to use Ipeak in the calculation of Iunb: Pros: a) This is the worst case
condition and the spec should handle it. b) 15% more than 600Ma*3%/2=9mA
is only 1.35mA this has negligible impact on the cost or form factor. Cons: a) Statistically the
chance that you will have BLW and peak power at max PD average power at PSE
minimum voltage during any 50msec time frame and all at the same time is very
small with the addition of if eventually you have some error it will be
corrected in next transmittion? Then low chances or no issue So it looks that either
way is easy to accept so I prefer the worst case i.e. Ipeak. Slide 22: This proposal
is also depend of how to ensure interoperability when Midspan is connected. Part
of the answer for this questions are depend on the answer to my first comment
on slide 17 i.e. if the system without MIDSPAN works fine with 120u on both
sides PSE and PD and may be more other issues that we need to examine here. Slide 22: Yes, more PDs port
are expected to ship than Midspan ports and we need to find for both cases a
cost effective solution. One of the solution that I would like the group to
consider that the magnetic component in the PSE or PD will have to meet a TBD
equation that I am working on that may help to get the objective as presented
in slide 22. Slide 23: Option 2a: can be good if
we can scientifically justify it. Option 2b is neither
practical nor cost effective. It was rejected by the 350uH ad hoc during the
discussions and it was rejected during the 802.3af project for any PSE type. That
is why this proposal was moved to the informative and not to the normative. Slide 24: a) I believe that there
is an error in the equation: Legacy Ibias in 802.3af=3%350mA/2
+8mA =13.25 K*600*400/350=13.25 K=1.93% b) This is not a
practical solution. It required special magnetic with splitted center tape + 2
capacitors for each pair. In addition it creates heat dissipation and may
require changing the PD voltage threshold specification and channel performance. The rest are good. Yair From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of ------------ Meeting materials
are attached ------ Hello, Proposed Agenda Please review the IEEE-SA
PatCom slides http://standards.ieee.org/board/pat/pat-slideset.pdf
prior to the start of our meeting. ______________________________________________________________________________ Date/Time:
SEP 3, 2008 at 8:00AM Global Access Numbers: TO ATTEND A WEB AND VOICE CONFERENCE: CISCO INTRANET ATTENDEES EXTERNAL ATTENDEES - Outside the Cisco Intranet** *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 SUPPORT |