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

10/100/1000 "4578" power

Perhaps I did not understand your question fully...
However, the attached schematic is one possibility for 10/100/1000 with power on the 
legacy "spare pairs". (we should just call them forty five seventy eight)

For 10/100 versions, the transformers shown on pins 4,5 & 7,8 would become tapped inductors,
or resistors, or even shorts.

- Rick Brooks

At 10:57 AM 05/12/2000 -0700, you wrote:
>You guys keep getting on Roger, but you still haven't articulated a
>solution for providing power for 1000BASE-T links.  If I open the latest
>version of the 802.3 specification published by the IEEE, there aren't any
>unused pairs.
>At 06:29 PM 5/11/00 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>>I have to confess. I am getting confused. In your earlier post you
>>suggested using 12,36 for switches and 45,78 for mid-spans, then 
>>when I raised the question of whether you were conceding that it was
>>better to use 45,78 for mid-span, you went back to stating that we 
>>have not shown 12,36 in the mid-span to be a problem which suggests
>>that you are moving away from the earlier position.
>>Your justification that some customers have only two pairs is valid,
>>but it has been decided to be insufficient to gain consensus in the
>>committee. Continuing to raise it is unlikely to turn the tide of 
>>support for a 4-pair solution.
>>If we are to have a solution, I believe it should be only ONE solution
>>that works in either the hub/switch, mid-span, or desktop-wall-wart
>>While I can appreciate your desire that the committee approve a solution
>>that supports Cisco's recently introduced product implementations, the
>>simple fact is that when you rush a solution out in advance of the
>>standards, you take a risk that your solution will not be compatible.
>>This has been proven time and again. I can think of many proprietary
>>solutions that were functional, but were not standardizable due to 
>>implementation constraints that were favorable to their designers, but
>>not to the industry as a whole. This is a natural outgrowth of the limited
>>review that proprietary specs receive.
>>Using the data pairs and a differential detection scheme seem to be at odds
>>with the objectives of our committee because they add risk and complexity to
>>the "must support 10/100T" and "must support mid-span
>>insertion" objectives. 
>>I have yet to see how someone would suggest that you can send differential
>>signals from a mid-span location down only one half
>>of the link and determine whether it is ready to accept power. How do you
>>isolate the other half of the link to prevent it from interfering with your
>>differential response?
>>In contrast, it seems intuitively obvious that one can inject a 
>>DC common-mode voltage onto one end of the link and evaluate the I/V
>>characteristics that the load represents. Since it it DC, it will be easy to
>>filter to reject noise emissions and induction. 
>>But lets not rely on one person's intuition, I wholeheartedly agree that
>>scientific measurement and analysis are the best method for deciding our
>>Best regards,
>>Dan Dove
>>HP ProCurve Networks
>>>  From: R karam [mailto:rkaram@xxxxxxxxx]
>>>  Sent: Thursday, May 11, 2000 2:54 PM
>>>  To: stds-802-3-pwrviamdi@xxxxxxxx
>>>  Subject: Dan- Again
>>>  Hi Dan
>>>  thank's for your input and 
>>>  here is my 2c on this.
>>>  >>  
>>>  >>    Thank you for asking- I am encouraged.
>>>  >>  
>>>  >>  Cisco's proposal has the following A, B sections.
>>>  >>  
>>>  >>  A- Use the Signal pair 1,2 and 3,6 to deliver power on a 
>>>  new switch.
>>>  >>  B- Use unused pair (4,5 and 7,8 ) to deliver power for mid-span.
>>>  >
>>>  >Intuitively, this seems to add complexity and I can not fathom
>>>  >why we would want to use different pairs depending on the 
>>>  >location of the power insertion. Given our objective of 
>>>  detecting power on
>>>  >the same pairs that it is inserted, this would require 
>>>  twice the amount of
>>>  >DTE-detection circuits and raise the issue of how to deal 
>>>  with switch vs
>>>  >mid-span insertion conflicts (ie: The switch sends 
>>>  Fat-Link-Pulses down
>>>  >12,36 and gets confirmation to send power while the 
>>>  mid-span sends its
>>>  >signals down 45,78 and gets confirmation on its pairs). 
>>>  This sounds like
>>>  >un-necessary complexity.
>>>  >
>>>  Dan, a bunch of things here,
>>>  1- we have yet to prove that going with the signal-pair (1,2 
>>>  and 3,6) in Mid
>>>     span is a problem.  We all think that it is risky based 
>>>  on common sense.
>>>      and chances are it could be. Fine and dandy for 
>>>  exisiting switches at
>>>      customer sites, we are not about to have them removed as 
>>>  some people claim.
>>>  2- why the signal pair, and why NO complexity:
>>>  a- there will be some customers with 2-pairs only, may be x% 
>>>  but there will be some.
>>>     and telling them look Mr customer, you did not follow the 
>>>  IEEE rules so
>>>     now you have to pay  does not sound like a valid reason 
>>>  to him and sounds like
>>>     a punishment to me.....
>>>  b- When I think about what it takes to do this standard, I 
>>>  envision a low entropy spec
>>>      where the scheme should be simple, clean and  does not 
>>>  require heavy duty
>>>      PHY-like level of intensity.  after all some  pulses 
>>>  will flag a DTE (phone say), you turn
>>>      power on, making sure that nothing will be fried ( & 
>>>  transient protection....).
>>>  c-  many little reasons come to mind so here is a Top 10 list:
>>>      So if we are selling a NEW switch, 
>>>      1- the intelligence for power and management can be in 
>>>  the switch 
>>>      2- the customer does what he always did, just plug and play 
>>>      3- less boxes and headaches at the patch panel
>>>      4- I as the wire-side engineer know that my circuitry is 
>>>  sitting behind
>>>         2000 volts of isolation, esd protected, and very 
>>>  possibly inside the phy
>>>         leaving me with a single Monitor-part at maximum and 
>>>  possibly little silicon if I had 
>>>         my way here at the wire-side! to do the JOB.
>>>         I am talking about zero circuitry on the board ( 
>>>  probably) for detection and a few
>>>         parts for power delivery. (transient protection and a 
>>>  power monitor)
>>>      5- the minute you require a lot of intelligence to be on 
>>>  the wire side and start to
>>>          think too much silicon, and at low voltage, you will 
>>>  enter into what could be a silicon
>>>          headaches in the field due to latch-up and transients.
>>>      6- I hear everyone- there will be some us who want to 
>>>  fry eggs off the ethernet cable,
>>>         charge batteries, but this differential scheme is 
>>>  begging to be used for ethernet-
>>>         networking enviornment where these phy vendors that 
>>>  we all beat up daily, who learned
>>>         so much over so many years the hard way, delivering 
>>>  some really challenging solutions
>>>         can be of help to us (and this is  not to vote for 
>>>  any of them).
>>>       I hear you, this is not optimal for the Egg cooker, but 
>>>  accomodating the egg cooker request,
>>>        to me is the added complexity.  The majority of us are 
>>>  doing 10/100/1000 Ethernet
>>>       So let's see both sides for a change.
>>>    7- Gigabit Again 1000BT <> (not equal) to 1000BT, and it 
>>>  is either 1000BT/100TX /10BT
>>>       or at least 1000/100, while  seeing each other can be 
>>>  fun every 2 month, brushing
>>>       this aside as un-necessary at this point may not the 
>>>  best approach here,  since 1000BT
>>>       makes signal pairs out of the 4-pairs in the cable, 
>>>  once we solve the signal- pair
>>>       issues we may be in for an addendum to the spec (if we 
>>>  elect not to tackle it now)
>>>       and we will not have to revisit this in 2 years.
>>>  8-  To this point, I am the optimistic one and feel good 
>>>  about this, what would be interesting is  if
>>>       we all get in with an open mind and possibly improve 
>>>  it, it may get us somewhere, years and
>>>      years of PHY, Magnetic, and RJ45 experience on our part 
>>>  and the vendors' can be put to make
>>>      such an approach a reality with minimum extra space 
>>>  needed  on the switch (due to density) this will prove
>>>      to be a blessing.   How much room are we left with at 
>>>  the RJ45 with high port count boxes,
>>>      The phy will have to be there, so shove as much into it 
>>>  as we can.
>>>  9- Say we run into a situation where more power has to be 
>>>  delivered, and it is impeded by
>>>       the Connector or wire, then having access to the 2 
>>>  signal  pairs is a blessing.
>>>       possibly allowing a power hungry device to be built.   
>>>  10- Again, drumming up the phy story, should this prove 
>>>  doable, and at this point I think
>>>        that it is, then designing Detection into the phy 
>>>  might prove to be a good option that 
>>>       is there for anyone to reach for.  We can look into 
>>>  this, it may be as simple as using
>>>       2 switches to use along with the POWER monitor 
>>>  circuitry existing on the unused pairs- 
>>>       plus the phy detection and there you get 2 schemes  in 
>>>  one.  Also If the DTE is built
>>>       to accomodate a single approach that could prove 
>>>  enough, but the added flexibility may
>>>       be 2-3 parts away.  So long that we try to keep an open mind.
>>>  These reasons are coming from myself and some of the issues that 
>>>  were raised at last meeting.   Of Course Larry's approach 
>>>  and yours have merit,
>>>  and your ideas possibly have advantages in some ways, let's 
>>>  look at each approach, at measurements,
>>>  and transients protection and see where this leads us to...  
>>>  I want you to know that I have
>>>  toyed with the single ended approach, where common mode 
>>>  pulses are sent in/out of RJ45,
>>>  and worried about noise, EMI and silicon on the wire issues.
>>>  Thank's
>>>  roger
>>>  >If you are conceding that using the unused pairs for 
>>>  mid-span is a better
>>>  >alternative than using the data pairs, please explain to me 
>>>  why we should
>>>  >use the data pairs for switch-based power insertion.
>>>  Dan, 
>>>  >
>>>  >Simplicity, and consistency would argue that we should just 
>>>  apply power in
>>>  >the unused pairs at both locations and reduce the number of 
>>>  alternatives by
>>>  >half.
>>>  >
>>>  >Regards,
>>>  >
>>>  >Dan Dove
>>>  >HP ProCurve Networks