Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-POEP] Baseline Bucket ad hoc



Hi Dan,

 

Thanks, it helps.

In the picture of the BLW that you have sent me, what is the period of the phenomena? I guess that when you load the Smartbit with the BLW packets, it runs periodically but the BLW is generated in a different period rate due to cable constant? (am I understand it correctly?)

Is the BLW depends on cable length? What is the minimum cable length that I should expect to BLW?

 

Thanks

 

Yair .

 


From: Dove, Dan [mailto:dan.dove@hp.com]
Sent: Thursday, January 10, 2008 4:56 PM
To: Darshan, Yair; STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: RE: [8023-POEP] Baseline Bucket ad hoc

 

Hi Yair,

 

Unfortunately, 100BASE-TX has strong signal content below 1MHz. When you run it through a high-pass filter, it will become distorted. The amount of distortion is a direct function of the pole location. If the 350uH adhoc were to come up with a spec for the MDI that eliminated the need to spec inductance, the *implementation* of a product would still be constrained to define that pole frequency.

 

In other words, suppose we came up with a template measurement. You could implement a compliant product by using a 350uH inductance with no silicon compensation circuits, or perhaps you could use 100uH with some silicon compensation, but that compensation would require the design to have a specific pole frequency or it would either over-compensate or undercompensate.

 

So, if we had a silicon compensation circuit designed for 100uH inductance, and then you insert another pole at some frequency down there, the result would be that your compensation was no longer tuned properly.

 

This problem is very specific to 100BASE-T as 10BASE-T has no baseline wander, and 1000BASE-T uses a scrambler polynomial that is so large it is essentially impossible to get baseline wander content sufficient to cause a measureable bit error rate.

 

I hope this helps.


Dan

 

 


From: Darshan, Yair [mailto:YDarshan@microsemi.com]
Sent: Thursday, January 10, 2008 4:25 AM
To: Dove, Dan; STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: RE: [8023-POEP] Baseline Bucket ad hoc

Hi Dan and all,

 

My team is working on the following action items:

 

  1. Checking ALT A with the "killer packet" to check the impact of BLW on the BER.
  2. To generate a Transfer function for a Midspan between TBDHz to 1MHz.

 

We started with item 2 and I hope to present data by next meeting.

Regarding Item 1 we are designing now the test setup for having enough data for recommending the best course of action.

 

 

I would like to have your opinion on the following:

 

The reason we are checking the behavior of a channel containing ALT A  Midspan is because we assume that it will affect the channel behavior at frequencies lower then 1MHz when we suppose to find the BLW frequencies.

My question is: If our ultimate goal per the 350uH Ad Hoc is to ensure meeting the minimum BER required so implementation will be transparent i.e. 350uH minimum inductance will be only one way to achieve it and other ways are possible, THEN meeting BER means also the effect on BER due too BLW.

If this is true, then why we care what is the Midspan transfer function at this low frequency band. If inserting the Midspan to a compliant Switch+channel+PD (i.e. a channel designed according 802.3 guidelines without compensation techniques etc. such as using 100BT SmartBit generator and standard channel and load)   and the BER test pass then the Midspan is compliant if it fails it is not compliant hence how the Midspan did it we don’t care and we don’t have to specify anything new.

Please let me know your opinion.

 

Thanks

 

Yair

 

 


From: Dove, Dan [mailto:dan.dove@hp.com]
Sent: Wednesday, January 09, 2008 8:00 PM
To: Darshan, Yair; STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: RE: [8023-POEP] Baseline Bucket ad hoc

 

Yair,

 

At the last meeting you mentioned that you had tested 100BASE-T with inline power on the data pairs and found no problems. During an offline discussion, we discussed performing testing with maximum length cables and the "Killer Packet" to ensure that your testing did not miss the impact of baseline wander on your testing. To assist, I sent you a copy of the Killer Packet (zipped binary) to enhance your testing.

 

Have you had an opportunity to evaluate the impact of inserting power into the data pairs using the Killer Packet since our discussion and do you plan to present on this?

 

I think it would be important to ensure that we fully characterize the exposure of inserting any additional low-frequency poles into the channel on 100BASE-T signal impairments.


Thanks,

Dan

 


From: owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Darshan, Yair
Sent: Monday, January 07, 2008 1:37 AM
To: STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: Re: [8023-POEP] Baseline Bucket ad hoc

Hi Matt,

 

Probably you didn’t see my email which I ask not to have meetings on Friday. Friday and Saturday are a non working days here like Saturday and Sunday' in North America.

Any way, please find below my comments/opinion regarding the base line bucket:

 

Comment #141:

Comment #141 deals with "Range of Maximum power used by the PD".

The commenter state that this column has no value and I disagree with him.

This column has value in which it specifies the range of maximum for better power management.

It is true that when you are using L2 you may not need this information however when using only L1, this information has value.

 

Regarding the argument that it confuses the average reader with the minimum power required to keep the port ON, I don’t see how it confused since the text is clear and if it still confuse we can add clarification but it is not justifying changing the level of information contained in this column.

 

I suggest rejecting this comment or ad clarification for the use of it in respect to 33.3.6.

 

Comment #124:

 

The commenter is basing his argument on the following assumptions:

  1. The existing PD detection section requires specific design requirements that are not necessary to ensure interoperability: This is not accurate statement. All the requirements in the specification are a result of extensive analysis and tests. Each of the requirements came to ensure interoperability.

The change it or modify it we need to td feasibility and economical tests/simulations. Non of it has been shown or demonstrated. 

  1. Pointing out to presentation made in September 2005: This presentation was "rejected in principle" by the audience at that meeting since it failed to accommodate false positive detection due to the time constant issue. Specifically, the standard recommend to take measurements after 5tau=1% of steady state in order to reduce the chance for false positive detection. So this presentation is a good example for what we should not do. There are other detection concepts that were discussed such as capacitor detection, AC coupled diode and other and the resistor concept was chosen as the preferred one which meets all objectives at low cost and high reliability.
  2. Figure 33-10 is no the PD model so it is not clear why it is related to detection issues as stated in the Suggested Remedy.
  3. Requiring PSE to detect values of Rpd_d for all permissible values of Cpd_d as specified in Table 33-2 is not practical and it is not required by the standard today. It adds unnecessary burden to the implementers with increased time constant problems.

Rational:

The current specification required to meet Rpd_d together with Cpd_d<0.15UF. This is possible and proven feasible.

Requiring meeting Rpd_d with Cpd_d>>0.15UF is technically problematic due to long time constants and false positive detection risks. There is a way to overcome this problem by using ac signals with source and sink capabilities however it requires technical and economical feasibility tests which if somebody present such it will be easier to consider and asses its technical and economical aspects.

  1. To delete the requirement of two point detection it requires to show that you can detect Rsig with out errors within single measurement. This is not an implementation issue. It is clear interoperability issue. If somebody can technically and economically prove that it can be done in other ways he is welcome.

 

I suggest rejecting this comment unless serious technical work will be presented to backup the changes suggested.

 

Comment #13:

 

This comment is similar in principle to comment #124.

Figures 33-8 and 33-9 are not mandating implementations.

It guarantees interoperability.

Figure 33-8:  

  1. Zsource>45K: Limiting energy backwards to PSE.
  2. Zsource>45K : Preventing 25K signature if two PSEs are connected together
  3. Vdetect and Zsource>45K allows meeting 30V open loop and 2.8-10V during valid signature with adequate resolution
  4. D1: Prevents two PSEs connected together in opposite voltage polarity to generate 25K signature
  5. D1: Prevents two PSEs connected together in opposite voltage polarity to generate 120V on the port/chips.

 

Figure 33-9:  

  1. Zsource not limited, with series diode D2: Limiting energy backwards to PSE.
  2. D1: Prevents two PSEs connected together in opposite voltage polarity to generate 25K signature
  3. D1: Prevents two PSEs connected together in opposite voltage polarity to generate 120V on the port/chips.

 

      The implementer can use any Thevenin equivalent of figures 33-8 or 33-9 which allows the flexibility which we are looking for.

 

In order to allow such big changes it is requires proving feasibility with different PSEs using different methods complying to the suggested remedy……!!!

 

Unless such proofs made I suggest to reject this comment.

 

 

Yair

 

  

 

 

 

 


From: owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of D. Matthew Landry
Sent: Friday, January 04, 2008 4:16 PM
To: STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: Re: [8023-POEP] Baseline Bucket ad hoc

 

Please find attached material for discussion during this morning's baseline bucket ad hoc.

Note in the meeting notice below, the 11:00AM starting time is Central Standard Time.


-matt

On Dec 11, 2007 11:53 AM, D. Matthew Landry < dmlandry@ieee.org> wrote:

Colleagues -

This message is announcing a comment resolution adhoc to discuss the remaining comments classified in the baseline bucket. This meeting will be administered by teleconference. Required materials will be sent prior to commencement of the meeting. The bucket of comments can be found at the following URL:

http://www.ieee802.org/3/at/comments/D1.0/P802d3at_D1p0_postmtg_bucket_baseline.pdf

Please take some time to review the IEEE-SA PatCom slides prior to the start of the telecon. I will ask if anyone has not reviewed the slides at the beginning of the call. If any attendees indicate that they have not reviewed the slides, time will be made available for such review. The slideset can be found at the following URL:

http://standards.ieee.org/board/pat/pat-slideset.pdf

The dial-in information is found at the end of this email. If you plan to attend, I ask that you RSVP  no later than the day before so that I can ensure that enough dial-in slots are available.

Thank you.

- matt


TELECONFERENCE DETAILS

Subject:
    IEEE 802.3at baseline bucket
Meeting ID:
    802302
Date/time:
    01/04/2008, 11:00 AM (US: Central (CST/CDT))
    01/11/2008, 11:00 AM (US: Central (CST/CDT))
Duration:
    1 hrs 30 minutes
Dial-in:
    International:
1.512.532.5999
    USA: 1.866.781.8274