Hi Yair, all,
A few things are getting confused here.
The NOPOWER state was added to provide permissible behavior for PDs that are in a powered condition, and then the voltage drops to in the Voff range.
The Type 2 state diagram also provided behavior for this condition, however that was an unintended side effect of the definition of a variable.
That state diagram says that as soon as the voltage is outside of the VPort_PD range, the PD must return to IDLE.
If the voltage then was again in the VPort_PD range, the PD would again end up in the MDI_POWER1 state, but was limited to Class 3 power, even if it had Class 4 power originially.
In short: this state diagram was so broken, nobody implemented it that way.
Some PDs chose to indeed freeze the class event counter in case of voltage dips, others "kept counting".
In order not to make otherwise compliant PDs non-compliant, the NOPOWER state sets the class counter to the highest possible value.
What we absolutely must prevent though, is that in any form of normal operation the PD state diagram passes through the NOPOWER state, because that completely breaks classification.
A number of problems have now been discovered:
1. PDs that use too low a value for the tinrush_pd timer can pass through NOPOWER because the capacitor is still being charged.
2. Overload and transients are all currently events that can pass a PD through NOPOWER, depending on the value that is chosen for VOff_PD.
Andreas' solution to remove the arc from POWER_DELAY to NOPOWER fixes issue 1, but as you point out, creates a small hole in the behavior in case voltage dips during those first 80ms.
What I would suggest is the following:
a) Change the definition of the tinrushpd_timer such that it runs precisely 50ms. That way, a PD either has reached a stable VPD, or it fails inrush requirements when it passes to POWER_DELAY.
b) Change Voff_PD to be a range from 30V to 36V. That means that under overload and transient conditions, the PD will stay in the POWER_DELAY or POWERED state and does not pass through NOPOWER.
I think that fixes all of the issues without creating new ones.
On Sun, 2017-10-22 at 08:45 +0000, Yair Darshan wrote:
Thanks, please see below.
From: Andrea Agnes [mailto:andrea.agnes181@xxxxxxxxx]
Sent: Friday, October 20, 2017 6:22 PM
To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Subject: Re: [802.3_4PPOE] PD state machine issues.
thank you very much for your shared issue related PD.
The state NOPOWER keep in account the exit way of a PD to reach turn off and the idea is limit the PD power up to 44mA during VPD<Voff_PD.
Yair: I understand that this was one of the objectives however right now what we add creates the two problems that I show, cause violating of the spec of compliant PDs.
Please note that compliant PDs will not need to use the exits to NOPOWER due to the fact that PD voltage is not allowed to consume more than Pclass_PD so there is no reason that VPD will go below VOFF_PD and PSE
is not allowed to reduce its output voltage below operating voltage during normal operation except transient overload or short circuit conditions which in this case we mat shut off the port or in case of transients which PD is required to work. The addition
of NOPOWER was added to handle PDs that from some reason their input voltage fall below Voff and then raised above Von which in the real world may happen and during the transition from Voff to Von the PD counts additional class event continue to count (which
compliant PDs doesn’t allowed to do, since the class event counter should be locked after the first time going to INRUSH) and people thought that we have aslo to handle this case.
So please consider how we address the issues of violating the 80msec timer and causing overload condition after entering the NOPOWER state. We have to fix this.
The introduction of a further variable that regulate a possible (or not) use of that way is not my preferred approach.
Yair: Please explain why if this is optional and compliant PDs doesn’t have the problems that cause PD to go to NOPWER.
Maybe is possible to evaluate to remove the exit from POWER_DELAY to NOPOWER.
Yair: We thought about this solution and it will fix part of the problem (the first issue). The issue with this solution is: If you believe that we should address the case when VPD<VOFF, you should address this in
all the states that the PD is powered including POWER_DELAY. Otherwise how you explain that your are doing in in POWERED and not in POWER_DELAY?
The proposed solution fix this problem by either you address is with the risk of having the two issues but then we don’t care since any way it was non-compliant behavior. Or chose not to use this option and then
there is no issues.
While the point related to the pse_power_level <==8 I think that your proposal is a right suggestion but it should be implemented in the definition of pse_power_level variable.
Yair: It is OK by me to address the
pse_power_level <==8 in the definition of pse_power_level variable.
2017-10-20 1:12 GMT+02:00 Yair Darshan <YDarshan@xxxxxxxxxxxxx>:
I found serious issues in PD single-signature state machine (the same issue relevant for dual-sig as well).
I’ll appriciate your inputs.
The PD state machine for single signature (and dual signature) has few issues concerning NOPOWER state and going back to INRUSH and back to POWER_DELAY.
Violation of tpowerdelay_timer when going from POWER_DELAY to NOPOWER.
Possible overload condition due to the assignment of (pse_power_level <== 8).
Allowing incompliant behavior of PDs that doesn’t lock their class event counter and sensitive to 2nd inrush counted as additional class event (I understand the need
for this but we need to allow it as optional behavior and not mandatory behavior for PDs. For example: If PD didn’t lost its data when going to Vpd < Voff_pd, it doesn’t need to set (pse_power_level <== 8) in NOPOWER spec so the correct assigned class will
not be destroyed.
When actual Tinrush_PD<25msec and transitioning from POWER_DELAY to NOPOWER state due to VPD<VOff_PD, sets nopower variable to TRUE.
nopower variable=TRUE will lead to bypassing tpowerdelay_timer (80msec) when returning back to POWERED through INRUSH and POWER_DELAY states which will lead to PD overloading the PSE which is still in INRUSH state. (The 25msec number is
due to the fact that we are going through INRUSH state twice in the above scenario)
This scenario happens whenever Vpd is lowered below Voff_pd in POWER_DELAY or POWERED states, causing a transition to NOPOWER state, then raised above Von_pd (regardless of the time VPD was below Voff_pd).
In the case where Tinrush_PD = 0 to 25ms, then the PD state-machine will do the transition from INRUSH to POWER_DELAY to NOPOWER to INRUSH to POWER_DELAY to POWERED in 2xTirush_PD.
This is a violation of Tdelay, which is minimum 80ms and may overload PSE by PD during INRUSH.
Same issue in dual-signature PD state machine.
In the NOPOWER state, the assignment "pse_power_level <==8" will cause PD to have pse_available_power=8 even if originally prior to getting to NOPOWER state is was lower than 8.
As long as VPD>VReset_th, PD remembers its data. In the arguments why we add it in the past, it was claimed that PD may think that we have additional class event when transitioning from NOPOWER to INRUSH again. This argument seems not correct
since PD required by spec to lock itself to ignore additional counts after first time going through inrush. Any way, we have big hole here.
Regarding PDs that doesn't lock class event counting, they are not compliant. I understand that we want to support this case in the field as well so we need to make the use of pse_available_power=8 optional as function if we lost the data
or not i.e. compliant PDs will not have to do it otherwise they may go to overload conditions while they behaves correctly.
In addition, we need to add text that explains that the NOPOWER state was meant to be use for abnormal use cases and not as the typical behaviour otherwise we by pass the mandory requirements of the spec.
Bottom line: We have tried to allow supporting non-compliant PDs or PDs that their behavior is not defined by making the state machine to support those PDs but on the way we create problems that compliant PDs doesn’t have and we
force them to behave in noncompliant way by violating other spec requirements.
Below is proposal to support those PDs without creating problems to PDs that behaves correctly.
[Allows the option to go to NOPOWER but not force it. This proposal is different than my previous proposal to Lennart and Tamir when I discuss the problem with them earlier]:
1. In the exit from POWER_DELAY to NOPOWER and in the exit from POWERED to NOPOWER, change the condition from VPD < VOff_PD to (VPD < VOff_PD)*go2nopower.
2. Add the new variable go2nopower:
Implementation specific variable that indicates if PD will go to NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED.
FALSE PD will not use NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED
TRUE PD will use NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED
3. Repeat only steps 1 for dual-signature PD in page 190 for the above states.
4. [This solution allow not using pse_power_level <==8 in case PD didn't lost its data or change its data during the transition to POWER_DELAY through NOPOWER)]
Append the following text to the definition of nopower variable:
"If pse_power_level data was not lost or changed in the event of transitioning to POWER_DELAY through NOPOWER, the assignment pse_power_level<==8 may not be implemented in NOPOWER”
Analog Mixed Signal Group