|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi Chris and Lennart,
It should be the objective off all PSE system vendors that spec should be correct and will support all CC_DET_SEQ as defined by this variable definition. This is currently not the case.
It is not sure that once we select CC_DET_SEQ option, we stick to it forever. As a result, we must ensure that all CC_DET_SEQ=0, 1, 2 or 3 in the state machine will be in sync with CC_DET_SEQ variable definitions.
I saw through my simulations that there are no issues with CC_DET_SEQ=0,1,2 regarding the transition from IDLE_SEC to START_DETECT_SEC. I saw the problem only in CC_DET_SEQ=3.
-The inputs from Chris just confirmed the interpretation of what we saw in the state machine but it doesn’t solve the problem when CC_DET_SEQ=3 when it used.
-What I see missing is to be able to do “staggered detection” in any CC_DET_SEQ that allows staggered detection without any limitations if power is applied to primary or not. This condition is not relevant to any CC_DET_SEQ unless you want to do 4PID without using the 3-finger technique.
-Lennart: Yes to, “I would also assume that this staggered behavior is intentionally used to verify 4PID for dual-signature PDs ?” but what if I want to use CC_DET_SEQ=3 and want to use the other 4PID method which uses 3 class-events? This is the issue that is not covered.
As a result, we will not break the 4PID mechanism of this sequence since per my proposal we can do the following:
(!pwr_app_sec * pwr_app_pri) +
( (CC_DET_SEQ=3) * option_probe_alt_sec * !det_start_pri * !det_once_sec )
+ (class_4PID_mult_events_sec*(CC_DET_SEQ=3) * !det_once_sec * det_once_pri )
The fisr part: (!pwr_app_sec * pwr_app_pri) covers the 4PID method when doing detection on secondary when power is on at the primary. This is existing today.
The 2nd part: ( (CC_DET_SEQ=3) * option_probe_alt_sec * !det_start_pri * !det_once_sec ) covers various cases when CC_DET_SEQ=3 is chosen. This is existing today.
The 3rd part is what is missing when you want to use (CC_DET_SEQ=3) AND you want to use the other 4PID method: + (class_4PID_mult_events_sec*(CC_DET_SEQ=3) * !det_once_sec * det_once_pri )
Thanks for making that clear. This confirms that a different interpretation of 'staggered' and 'parallel' lies at the base of this request. In essence, what Yair wants to do is possible using sequence 0 or 1.
What we may want to do is expand a bit the explanation of CC_DET_SEQ 3, because it misses this key bit of information that the second pairset can only proceed with detection after the first is powered on.
I would also assume that this staggered behavior is intentionally used to verify 4PID for dual-signature PDs ?
So, if we allow detection to happen before the first pairset of powered on, we'll break the 4PID mechanism of this sequence ?
On Fri, Sep 1, 2017 at 6:08 PM, Chris Bullock (bullock) <bullock@xxxxxxxxx> wrote: