Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Leon, Good question. However, if, for the time being forget that we can define a reliable optical threshold detect, how would you want to address this?
The key issue for the comment is can we identify a suitable optical signal detect and associated level. So far, we didn’t see any reliable way. I believe we will need to rely on the fact that the various black link crosstalk requirements in Table 154-10 are sufficient that a potential crosstalk signal
is sufficiently weak that it will not be possible for a receiver to lock onto Kind regards, Peter From: Leon Bruckman
Hi, I have no objection to this approach, but I have a question: Is there a possibility that there is a signal loss (no intended signal in the channel) and still the receiver sees a weak cross talk signal from an adjacent channel
? If this is possible then the receiver may lock (an probably unlock intermittently) to that signal.
A SIGNAL_DETECT optical power threshold would avoid this situation. Is there another mechanism to detect this situation (if this situation is possible at all)? Best regards, Leon From: Peter Stassar [mailto:Peter.Stassar@xxxxxxxxxx]
Hi,
Because I had some thoughts after our call yesterday, I contacted Eric and Steve Trowbridge to get some feedback. Apparently the three of us had independently come to a similar conclusion, that the SIGNAL_DETECT in Clause 154 is so unreliable for the intended applications,
that we doubted the usefulness of it. The three of us jointly feel that it will be impossible to define a suitable optical threshold that is also reliable and furthermore that the “real” signal detection
actually is in the higher layers and not so much in the physical layer. Thus we recommend to the group to remove the allocation/definition of an “exact” optical level for SIGNAL_DETECT. Instead we recommend to assign a fixed OK status to SIGNAL_DETECT, in order to not mess up with the interlayer relationships. Via this email I would like to check if there would be any objections to that approach. If there are then Eric will move forward and set up an ad hoc to further discuss. If there are no objections, then we can use this principle towards a suitable modification of the draft. Before starting to develop appropriate text to describe this I would like to know your views. Please let us know latest coming Monday 22 July. Kind regards, Peter Stassar, Clause 154 editor From: Eric Maniloff [mailto:eric.maniloff.ieee@xxxxxxxxx]
All, I was asked to set up an Ad Hoc call on the Signal Detect issue. I'll be organizing this for late next week or early the following week, please let me know if you are interested in participating by replying to this email. Scheduling is challenging, so please also let me know if you are participating in 802.3ck calls, and where you are located so I can try to accommodate schedules (with no promises). Regards, Eric To unsubscribe from the STDS-802-3-DWDM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 To unsubscribe from the STDS-802-3-DWDM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 |