compliance, 11.3, d: take delay_resp cf into account
11.3 d says: Upon receipt of the Delay_Resp message by the slave: 1) If the received Sync message indicated that a Follow_Up message will not be received, the <meanPathDelay> shall be computed as: <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message - originTimestamp of Sync message) - correctionField of Sync message - correctionField of Delay_Resp message]/2. 2) If the received Sync message indicated that a Follow_Up message will be received, the <meanPathDelay> shall be computed as: <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message - preciseOriginTimestamp of Follow_Up message) - correctionField of Sync message - correctionField of Follow_Up message - correctionField of Delay_Resp message]/2. We assume that: t1 = originTimestamp of Sync message (one step) or t1 = preciseOriginTimestamp of Follow_Up message (two steps) and t4 = receiveTimestamp of Delay_Resp message wich is true for masters not supporting sub-nanosecond timestamps (we don't support sub-ns precision via standard protocol, so the assumption should be true for us). As sync (or followup) arrives, we calculate m_to_s_dly, which is: t2 - t1 - cf_sync - cf_followup When delay_resp arrives, we calculate s_to_m_dly, which is: t4 - t3 - cf_delay_resp So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to: (t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2 which looks like the 11.3 d expression for mean path delay (note that cf_followup is zero for a one-step master). To get this result, we just save the delay_resp cf to ppi->cField.
Showing
Please
register
or
sign in
to comment