Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I Chad, Never say never. We made a good progress since the time some said,
“we have no issues at all” until now we have address more than 10 topics and found 3 at least that corrected by additional text. And I don’t believe it is FUD. This is in my opinion the difference between a good and clear spec to something else. How would you know without checking if you have a problem? Yair From: Chad Jones (cmjones) [mailto:cmjones@xxxxxxxxx]
EXTERNAL EMAIL In my opinion, backfeed is purely about detection which means 10.5V. There is slop in the classification range that allows us to ignore there, but I could be convinced 20.5V. after class, none of it matters. You could never convince me
that 30V is required. But, I don’t think any of this needs to happen. This theoretical PD that backfeeds under 3P power enough to spoil detection fails other PD requirements (as this is now a 4P standard). Backfeed is a 2P spec, written for a purely 2P problem.
This additional restriction is FUD that is making us spin around the drain and threatening to make us miss the July submission date. Chad Jones Tech Lead, Cisco Systems Chair, IEEE P802.3bt 4PPoE Task Force Principal, NFPA 70 CMP3 From: Yair Darshan <YDarshan@xxxxxxxxxxxxx> Chad, In your opinion, from which voltage in 3-pair mode, the PD doesn’t need to meet backfeed requirement (2.8V, 28uA)? 10.5V and up? 20.5V and up ? 30V and up? Yair From: Chad Jones (cmjones) [mailto:cmjones@xxxxxxxxx]
EXTERNAL EMAIL Heath, your review includes this statement: Moving the PD requirement to the PSE is onerous and moves requirements from the out-of-spec PD to the compliant PSE. I disagree with this statement. This is not an out of spec PD. The PD 100% complies to the backfeed spec as written in Clause 33. We carried forward that requirement simply because we copied 33. As I’ve said repeatedly, the backfeed requirement
is a true 2P requirement. When you apply 3P power, you are not performing this test and the requirement no longer applies. The real first question we should have asked is does a true 2P test belong in a 4P standard. This is no longer simply a ‘FET bridge’ problem. It’s been reported on this reflector that schottky diodes also fail the misapplied 3P backfeed test. The PD is only “misbehaving” because the PSE is improperly applying 3P power. If you want
to outlaw this behavior, then you are mandating silicon diodes. This standard fails if that is a requirement.
This is a PSE misbehavior that we decided to make compliant. The PSE holds the burden to fix.
Chad Jones Tech Lead, Cisco Systems Chair, IEEE P802.3bt 4PPoE Task Force Principal, NFPA 70 CMP3 From: "Stewart, Heath" <Heath.Stewart@xxxxxxxxxx> As always we appreciate your ongoing work. We continue to have some concerns regarding the PSE requirements. As written they do are in effect during 4-pair power operation (and at all other times,
without limit.) We consider a PD which presents a reflected voltage (above Vrefl) during classification to be undesirable. As such we have marked up your presentation to suggest some changes. Cheers, -Heath From: Lennart Yseboodt [mailto:lennart.yseboodt@xxxxxxxxxxx]
Hi Heath, v220 and v230 correspond to both approaches we discussed during the adhoc call. At the end of the call, I believe the consensus was to split Irev into two values (for >21V and <21V), which corresponds with v230. Overview: v220 - PSE requirement Irev is 1.3mA and applies when applying 2-pair (=3-pair) power on the unpowered negative - PD has to safeguard classification, hence has a 3P-backfeed requirement from 0-21V v230 - PSE requirement is split into 500uA when highest pairset voltage <21V and 1.3mA when highest pairset voltage >21V - Because the PSE has a current limit that does not corrupt classifcation in the classification range, the PD is only required to limit 3P-backfeed in the detection range
0-10.1V The advantage of v230 is that it allows for wider implementation of PD bridges. Kind regards, Lennart On Thu, 2018-05-10 at 16:05 +0000, Stewart, Heath 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 |