# Plateau detectors **URL:** \ **Category:** GNU Radio\ **Created:** [November 22, 2014, 2:05pm UTC](https://www.ruby-forum.com/t/plateau-detectors/233186 "2014-11-22T14:05:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [November 22, 2014, 2:05pm UTC](https://www.ruby-forum.com/t/plateau-detectors/233186/1 "2014-11-22T14:05:38Z")
Hello all: I have read the code of “Schmidl & Cox synchronisation”.And I find the code use the plateau detectors.It shows that the code will output 1 at the middle of the plateau.Why not in the first place of the plateau instead of in the middle of the plateau? Thank you very much. Best regards, zs ---
**Author:** ![swx\_z](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@swx\_z](https://www.ruby-forum.com/u/swx_z)\ **Post date:** [November 22, 2014, 6:03pm UTC](https://www.ruby-forum.com/t/plateau-detectors/233186/2 "2014-11-22T18:03:15Z")
Hi zs, hm, there’s basically three places (that I know of) that GR uses Schmidl & Cox: the ofdm\_chanest Channel estimator, the original S&C-based ofdm\_sync\_pn.py and the more robustness-optimized version in ofdm\_sync\_pnac.py. I suspect you’re referring to one of the two ofdm\_sync\_pn\*.py , but they differ a bit in how they deal with the peaks. Thus: Which implementation are you referring to exactly? Generally, Schmidl & Cox [1] states that “The timing metric reaches a plateau […] For the AWGN channel, there is a window with a length of the guard interval where the metric reaches a maximum, and the start of the frame can be taken to be anywhere within this window without a loss in the received SNR.” Thus, without having really read throu ofdm\_sync\_pn.py in depth, if using the original approach, you shouldn’t even care where the plateau is converted to a 1. Greetings, Marcus [1] [http://scholar.google.de/scholar?cluster=3934179950738780116&hl=en&as\_sdt=0,5&as\_vis=1](http://scholar.google.de/scholar?cluster=3934179950738780116&hl=en&as_sdt=0,5&as_vis=1) ---
**Author:** ![swx\_z](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@swx\_z](https://www.ruby-forum.com/u/swx_z)\ **Post date:** [November 24, 2014, 3:09pm UTC](https://www.ruby-forum.com/t/plateau-detectors/233186/3 "2014-11-24T15:09:44Z")
On 11/22/2014 06:01 PM, Marcus M. wrote: > Hi zs, > hm, there’s basically three places (that I know of) that GR uses Schmidl > & Cox: > the ofdm\_chanest Channel estimator, the original S&C-based > ofdm\_sync\_pn.py and the more robustness-optimized version in > ofdm\_sync\_pnac.py. > I suspect you’re referring to one of the two ofdm\_sync\_pn\*.py , but they > differ a bit in how they deal with the peaks. Thus: > Which implementation are you referring to exactly? He’s probably referring to plateau\_detector\_fb. > Generally, Schmidl & Cox [1] states that > “The timing metric reaches a plateau […] For the AWGN channel, there > is a window with a length of the guard interval where the metric reaches > a maximum, and the start of the frame can be taken to be anywhere within > this window without a loss in the received SNR.” > Thus, without having really read throu ofdm\_sync\_pn.py in depth, if > using the original approach, you shouldn’t even care where the plateau > is converted to a 1. This. Also, how do you detect plateaus? Have a look at the code. Finding the middle is easy, but how do you know you’re at the beginning? M