| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Sure the definition by itself is fine. Peter From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
I hear you – and see the issues you’re pointing out. The constraining of the messages though sounds like a different comment – something to make on a future draft. The nature of the information is what it
is…. Not sure why you’d want to falsely represent timing lock is ok… George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From:
Peter.vanDyck@xxxxxxxxxxxx <Peter.vanDyck@xxxxxxxxxxxx>
My concern is e.g. 191.5.2.4.4 Message Field: FOLLOWER. Any other value shall not be transmitted and shall be ignored at the receiver.
The Message Field setting for the first transmitted PMA frame shall be the first row of Table 191–5 for the LEADER and the first or second row of Table 191–6 for the FOLLOWER.
Moreover, for a given Message Field setting, the next Message Field setting shall be the same Message Field setting or the Message Field setting corresponding to a row below the current setting. When loc_rcvr_status
= OK the Infofield variable is set to loc_rcvr_status<5> = 1 and set to 0 otherwise. To me that reads like any other Message Field (to me it is the whole row), is not permitted. That means a row where timing_lock_OK or loc_rcvr_status goes back to 0 is not possible. Thanks, Peter From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Yes, it isn’t an assumption – it is behavior. Timing lock can be lost after it has been required, and if it is, the bit flips from 1 to 0 (and hopefully back to 1 when it is reacquired again). George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Peter vanDyck <00005eed8bd3e774-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi George,
is the assumption that timing_lock_OK could be lost after a “1” has already been transmitted to the link partner, and that loss would be transmitted again through the infofield?
It’s not clear to me from the “is set to zero otherwise”.
Peter From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Ragnar – I was struggling with precise words for the implementation-specific nature of determining whether the follower was tracking... If you can provide some, I would be grateful. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
I agree with George's comment. I would expect the initial condition to be 0 (FALSE), and then transition to 1 (TRUE) when the follower has acquired the timing lock. Therefore it is more appropriate to talk about setting timing_lock_OK=1
when timing lock has been acquired and set to 0 otherwize. There should also be a statement about the implementation of the timing_lock_OK condition is implementation specific. Ragnar On Mon, Jul 13, 2026 at 8:18 AM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 |