| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Yair – your argument would be correct IF the standard were the ONLY document or source of information available to the PD designer. I won’t be, and already isn’t. Unless this is
a new requirement (rather than a pointer to another place in the document) the standard is complete and doesn’t need it. I understand your desire to make the standard more understandable, but the large number of cross references within the standard is actually
making it less understandable. At some point the reader stops following those “see x.y.z” statements because they have become too numerous. In my opinion, they already have. It would be far better to take the more detailed explanation of the situation
(which you have nicely provided in this thread) into an explanatory or tutorial whitepaper or other publication to help the PD designer.
George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Hi Chris, All what you said is true but it is not easy to understand the effect of Irev on PD. See how much work I and others invested to investigate the potential issues, we have found issues and as a result we change the proposed baseline until we clear all issues. We did
it for every function. We didn’t do it for MPS. Now I am trying to complete my work and address this item to. As I said in my previous mails: This is the first time that setting a PD parameter is depend on other PSE parameter in a very complex scenario: PSE is a 4-pair but operate in 2-pair that is actually 3-pair and is connected to a PD that uses ideal diode bridge that if it gets 3-pairs due to design mistake (that many of us
did..) is backffeding and as a result anything that exists at the PSE unpowered pair is reflected and became part of the PD signature, PD class (new news: PD MPS) which may alter its performance.
Now, how a PD designer will understand all of this in fair amount of time without being part of our group or without given a hint to look for this dependencies? The key issue is: we had never had a parameter specified in the PD that is affected by a parameter in the PSE. Please check and verify that until D3.4 all PD
initial parameters where set only by the PD and PSE has zero control on it. D3.5 violates this concept and we need to make sure that we are not misleading the reader. Yair
From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL Hi Yair, In clause 33, we did not mention Ihold in the PD section. If the PD designer wanted to implement the feature that you are talking about, he would have
had to read the PSE section to understand the Ihold thresholds and timing. The same is true in 802.3bt, except now the PD designer needs to read the PSE section to understand Ihold and Irev. This is nothing new. Thanks, Chris From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Hi Chris, Not sure that I understand the question. In clause 33, we are working on 2-pair. When working over 2-pair, you need to meet backffed at any voltage (detection , classification powerup/on) which means maximum 2.8V over 100K
i.e. maximum 28uA. This means that nothing is reflected from the unpowered pair to the signature resistor, classification current or MPS. So, we don’t have problem and PD set its MPS current per the
PD needs without the concern that something in the PSE will affect the MPS current. In 802.3bt D3.5 in a 4-pair system, when we operate in 2-pair (which is 3-pair), we need to address the case of the PDs with the ideal diode bridge that doesn’t
meet backfeed in 3-pair. This behavior cause to any impedance on the PSE on the unpowered pair to be reflected in parallel to the PD elements and cause that to change their total value which ends up with change of resistance or current at the PD. In our case it is the MPS. The MPS current is affected by Irev which is generated in the PSE on the unpowered pair. So, a PD is set its MPS in order to be disconnected but due to
Irev in the PSE, the PD MPS setting will be changed and present a new value that may end with keep the PD powered which was not the intent of the PD!
Now in order to not mislead the PD designer, in case he is not aware of Irev because Irev is not in the PD spec, I suggest to tell the PD that he need to be aware of Irev when he
sets the value of the PD MPS in order to achieve the PD goals. Yair From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL Hi Yair, In clause 33, we did not tell the PD designer about Ihold. Why is this different? Thanks, Chris From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Hi George, I am not necessarily suggesting new values or more informative information etc. This is not my intention. You are welcome to offer simpler text. I can’t agree to leave this as is. Again, the problem is: If PD vendors don’t read PSE section, how they can be aware of Irev in 3-pair mode which is in the PSE section and affect
the MPS on the PD section? Before we wavered on backffed requirements in 3-pair mode i.e. backfeed was required to be met and all PSE voltage range, we had never this situation before that meeting the PD spec
depends on PSE spec. This situation will be a source of interoperability issues and I am trying to resolve it at ZERO cost/issues for the ideal diode bridges in the field (instead of asking again to disallow new Type 3 and 4 PDs from having backfeed issues
in power on state). Without adding some hint/link/text to the PSE Irev in PD MPS clause, we will mislead the PD designer.
Please note that my proposed approach was the normal approach we took in similar cases. This is no different than the other cases. Yair From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL Yair – all of these values are tutorial in nature. There are no requirements in your proposed text, therefore they are completely advisory. We write standards – the important thing to capture is what is required. The information may be valuable to implementers, I don’t argue that. However, publish that elsewhere (for
example, in an EA whitepaper) if you so desire. George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Hi George, The value of the proposed text is much higher that you have described see why: The issue is: -PD operates in 3-pair mode with ideal diode bridge that has the backfeed issue. This means that whatever load is in the unpowered PSE alternative, it is reflected to the PD load
and added up. -PD wants to be powered off. As a result it sets its MPS to 3.9mA which means must be OFF. PD vendor may not be aware of the Irev spec since it is in the PSE spec. -Now in this condition Irev=1.3mA will be added from the PSE to the PD MPS i.e. 3.9mA+1.3mA=5.2mA and PD will not be disconnected. This is the problem. The solution is that the PD vendor will take the 1.3mA in account of the MPS setting. The problem is that the PD vendor is not aware of Irev since this is the PSE spec and many times as a response to comment we agree to add text to PD section to tell PD about parameters
that affects the PD but appear in the PSE i.e. we said that the PD vendor get a PD spec and start to design without looking on PSE spec or aware of it which I believe it is a correct scenario. By the way, during last meeting we change the PSE and PD spec to address similar issues concerning to the effect of Irev on other spec items and this is one of them. I can never agree to a situation that you have a clear requirement in a PD for what to do regarding MPS (or other spec items) without telling the PD vendor that there is something
waiting for him in the corner… in the PSE spec that is not mentioned in the PD spec that can make his PD uncompliant. I don’t see a reason to
hide such critical information. Yair From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL
Yair - the proposed text is purely advisory and informative. At this stage we should only be concerned with missing or incorrect requirements or correcting (preferably deleting) incorrect information. I just don’t see the point of adding more informative advice
to the standard. George A. Zimmerman, Ph.D. CME Consulting, Inc. Experts in PHYsical Layer Communications 310-920-3860
Hi Lennart, I agree that it doesn’t affect the case when the PD is disconnected from the cable. I was referring to the case that the PD is connected and wants power removal. The question if it is rare or not, is irrelevant since it is already in the spec and we need to address
it somehow and meet it. I agree that the solution can be that PDs that do want to have power removed can set their Iport_mps value for power removal to be lower than (4mA-1.3mA)=2.7mA. However, in order
to make this clear to the PD vendor (since Irev is in the PSE section) I believe that we need to add text to the PD MPS section as follows (or equivalent): Proposed remedy: Add the following text in clause 145.3.9, page 222 text after line 49: "When a PD is operating under 3-pair mode conditions, the value of IPort_MPS as seen by the PSE over the powered pair may increase by Irev (See 145.2.10.4, 145.3.8.8 ). As a result,
the PD may need to set IPort_MPS to alower value than IPort_MPS min to ensure power removal." Yair From: Lennart Yseboodt [mailto:00000b30a2081bcd-dmarc-request@xxxxxxxx]
EXTERNAL EMAIL Hi Yair, Your analysis is correct, the reverse current is added to the PDs own current. I don't consider this an issue we need to do anything about however: - it does not impair the primary function of MPS in any way (to remove power when the PD is disconnected) - it only affects PDs that use the method of removing MPS in order to have the PSE remove power, I would say this is pretty rare; - PDs that do want to have power removed can accommodate for the maximum 1.3mA of reverse current (draw less than 2.7mA of their own) Note that reverse current only happens under 3-pair conditions, and then the 'must disconnect' current level is 4mA for PSEs. Kind regards, Lennart On Mon, 2018-06-11 at 12:03 +0000, Yair Darshan wrote:
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 |