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

Re: [802.3_4PPOE] Channel P2P RUNB



My concern is largely what does the PSE magnetics guy need to design for in the offset current. 


The individual transformer (for one pair) offset current is has been thought to be a % of its total current (due to system system components i.e. magnetics, connectors, cable resistance offsets).  Also the OCL (inductance) is a function of temperature which has a current squared heating effect.  As an example 20% higher current gives them 1.44 times more heating and 20% more offset current to first order.


An imbalance specification at the PI for current in a pair fixes all of my concerns and we have voted in a straw poll that this is needed.  Is this or should it be what our Ad-hoc is shooting for?  We are studying the overall of the system well beyond the PI but at the end of the day is this going to lead to a PI specification on imbalance?




Jeff Heath
Design Center Manager

Description: Linear Technology Corporation




402 East Carrillo Street, Suite D


Santa Barbara, California 93101









From: Darshan, Yair [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Monday, April 28, 2014 4:48 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Channel P2P RUNB


Hi George and all,

Many thanks for your response. I am fully agree with most of it. To some of it I would like to response below to go further deeper in our discussion.

Please see my response below.



From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, April 29, 2014 12:08 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Channel P2P RUNB


Fred & all  –

I believe this straw poll is about what we think the standard needs to say, to build consensus, not a survey of customers.

Yair: Yes this is correct and is the intent.



I too would not want specific temperatures and environmental parameters in the standard.  This would be contrary to existing 802.3 practice. 

Yair: Fully agree.


I would generally not support an informative section on effects of temperature, as it will end up being implementation specific, confusing, and won’t add to interoperability.

Yair: Yes this argument make a lot of sense and that is why I proposed also the other alternative to follow 33.7.7.


I think we should treat these issues as Yair stated on slide 6 of his presentation with the standard text from clause 33:

33.7.7 Temperature and humidity

The PD and PSE powered cabling link segment is expected to operate over a reasonable range of

environmental conditions related to temperature, humidity, and physical handling. Specific requirements and

values for these parameters are beyond the scope of this standard.

Yair: Agree, see above.


I disagree that this means to “focus on results at room temperature”, but rather, that individuals looking at the specifications we make (for example, for imbalance in the PSE PI)  will have to consider what temperature range they can reasonably meet those specs over, and whether that is sufficient for their product needs.  These are individual determinations, but can be driven by technical presentations.  Remember though, we don’t spec the component parts (e.g., magnetics) or their temperature range, we spec the PI as a port and its electrical parameters.

Yair: I fully agree with it but we need some practical anchor to start with. Let's agree that clause 33.7.7 is not about room temperature.

We also agree that system vendor once he decided that his system need to work at 0degC to 50degC, he need to make sure that at 0degC he meets CP2PRUNB. Now the question is: What is the minimum temperature that we need to calculate CP2PRUNB and set it as specification requirement? (CP2PRUNB is worsen as temperature is going low mostly due to copper components effects).

If we set the CP2PRUNB at room temperature which is now 26.2%, The system vendor will have to do research, testing etc. to find what will be this number at 0 degree, so we can specify this number at 0 degree and this vendor will be OK. The same analysis game we can do with other vendor that works at -20deC to 50C. Now the spec is not covering his need and he needs to do research and testing etc. to figure out what to and so on.

So bottom line what is the minimum temperature that we will specify CP2PRUN? It looks that any number we pick we will have "what if question" as I shown above.

So 25degC is good as any other number so for Temperature below that number ,  the vendor will need to do his research etc.


This same (or very similar) language is repeated again and again in IEEE Std. 802.3, and is also the way PHYs are tested.  In my opinion and experience, it is up to manufacturers (of both components and boxes) to specify their temperature range and compliance points.  For example, if a product says it is compliant with 802.3at, and is designed for a temperature range of  0°C to 70°C, then it should meet its specifications (including compliance) over that temperature range.  I have been involved in thermal chamber tests where (PHY and box) products are tested at their temperature corners.  While all compliance tests aren’t performed, if a functional or interoperability problem is found at temperature, those are followed up on. 

Yair: I agree that this should be the concept and we need to do it . We also don’t want to specify CP2PRUN at for example -50degC so not to force overdesign.

So we need to discuss all the above and have some optimal suggestion that will not create interoperability issue e.g. PD vendor meets PD PI P2PRUNB at  -20C to 50C,  connected to a PSE with PSE PI P2PRUNB at 0C to 50C through a cable installation CP2PRUNB at TBD operating range. I believe that we will have such  concept and I am working on it.


IEEE 802.3 specifies the range (independent of temperature) of electrical parameters that are needed for interoperability, and should do the same for PoE.

PHY products have, for example, frequency accuracy specs that need to be met across the design temperature range.  Manufacturers make choices of what temperature they will design to (some do 0 to 70, some do  -40 to 85, etc.), and need a compliance spec they can test to.

Yair: I fully agree that IEEE 802.3 specifies the range (independent of temperature) of electrical parameters that are needed for interoperability, and should do the same for PoE. This is our starting point, i.e. now that we have a number for Channel P2PRUNB of 26.2% (worst case analysis at 25degC) we are discussing how to proceed with it.



George Zimmerman

Principal, CME Consulting

Experts in Advanced PHYsical Communications Technology






From: Fred Schindler [mailto:grog06@xxxxxxxxx]
Sent: Monday, April 28, 2014 9:38 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Channel P2P RUNB - Ad-hoc list of attendees - UPDATE


Hi Chad,


I misspoke.  Yair is doing a straw poll with three choices.  I felt a choice was missing and started this email chain.  In my email, I used the word survey as equivalent to straw poll although I now realize they are not equivalent.







From: Chad Jones (cmjones) [mailto:cmjones@xxxxxxxxx]
Sent: Monday, 28 April, 2014 7:01 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Channel P2P RUNB - Ad-hoc list of attendees - UPDATE


What is this: “I do not think this is a choice in the P2P ad hoc survey but it should be”? Is there a plan to do some sort of survey? Can you provide details?


Chad Jones

MGR, HW ENG, Cisco Systems

Chair, IEEE P802.3bt 4PPoE Task Force



From: <Darshan>, Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Reply-To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Date: Monday, April 28, 2014 at 7:42 AM
To: 4PPOE Reflector <STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_4PPOE] Channel P2P RUNB - Ad-hoc list of attendees - UPDATE


Hi Fred,

Thanks for your inputs.

So you prefer?

a)      Single worst case number at room temperature?

b)      Single worst case number at TBD  low temperature were this low temperature represents wide market applications? (and no further text/inputs/requirements/guidelines for lower than that minimum temperature point?)

c)       Else?


I understand from your response that you prefer option (b)?



From: Fred Schindler [mailto:grog06@xxxxxxxxx]
Sent: Sunday, April 27, 2014 7:23 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Cc: Darshan, Yair; ieee@xxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] Channel P2P RUNB - Ad-hoc list of attendees - UPDATE


Hello Pair-to-Pair Ad Hoc,


I think adding temperature details to the IEEE .3BT specification will result in problems.  Stating values at temperature is not standard for IEEE specifications.


Not all vendors will operate in the same temperature range.  Requirements should be provided for interoperable operation.  Some of this may be arrived at by considering temperature for the broader market.  Vendors with wider operational needs will need to use cable made for the application and tested with .3BT requirements. Guidance for cable parameters should reference cable standards. The .3BT standard should provide guidance on how to use cable standard values for the .3BT standard.


ð  I do not want parameters for specific temperatures in the requirements of the .3BT specification.


I do not think this is a choice in the P2P ad hoc survey but it should be.  That is, I do not want this information in the appendix either as this will require .3BT to wait for cable standards to provide the values.  Values in the appendix are not tested.


Thanks for your consideration,


Fred Schindler



From: Darshan, Yair [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Sunday, 27 April, 2014 3:09 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: [802.3_4PPOE] Channel P2P RUNB - Ad-hoc list of attendees - UPDATE


Hi all,


Please review if I missed your name in the list of attendees on last Thursday a-hoc meeting.




  • Yan ZHUANG
  • Ronald Tellas / Panduit
  • Larsen, Wayne /
  • Jeff Heath
  • Brian Buckmeier
  • Rick Frosch / Phihong
  • Christian BEIA / ST
  • Leonard Stencel / Bourns
  • Fred Schindler / Seen Simply
  • Koussalya Balasubramanian / Cisco

§  David Tremblay / HP



Darshan Yair


Chief R&D Engineer

Analog Mixed Signal Group

Microsemi Corporation


1 Hanagar St., P.O. Box 7220
Neve Ne'eman Industrial Zone
Hod Hasharon 45421, Israel
Tel:  +972-9-775-5100,

Cell: +972-54-4893019
Fax: +972-9-775-5111


E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>.