Re: [Discuss-gnuradio] Sync short in gr-ieee802-11

[Bastian Bloessl]

Hi,

On 04/18/2017 04:34 PM, Nikita Airee wrote:
> Hi again, a few quick questions.
> 
> How do you decide on the values of MIN_GAP(480) and Max frame size(540*80)?

I chose MIN_GAP to correspond to the shortest possible frame.

MIN_GAP(480) = Preamble (320) + Signal field(80) + at least one data
symbol (80)


> 
> If during reception, one frame arrives within 480 samples of the other,
> say within preamble duration of the first, are the subsequent samples
> are copied anyway because the block is in copy state?

Then you have an interference situation. If one frame is much stronger
"Sync Long" will hopefully align reception with the stronger frame. (It
searchers for the maximum correlation with the known pattern of the long
preamble within a window of 320 symbols, IIRC.)

If the interfering frames arrives 320-480 samples delayed, it will just
interfere.

If it arrives more then 480 samples later and manages to raise the
autocorrelation coefficient high enough, Sync Short will mark the
beginning of a new frame and the receiver switches over to the new frame.

Best,
Bastian


> 
> Bests, 
> Nikita
> 
> On Apr 12, 2017 9:38 PM, "Bastian Bloessl" <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Hi,
> 
>     On 04/12/2017 03:49 PM, Nikita Airee wrote:
>     > Oh yes it does! But how does MIN_GAP come into the picture? Is it the
>     > minimum gap required between 2 frames for the second to be
>     detected as well?
> 
>     Yes. At the beginning of a a frame, the autocorrelation stays high for
>     some time. This makes sure that frame detection is triggered only once
>     per frame. It is the minimum number of samples between successive
>     triggers.
> 
> 
>     > Also if I'm not wrong the first frame is simply discarded when the one
>     > coming after is detected because there seems to be no provision for
>     > keeping the stronger frame and discarding the weaker one?
> 
>     Currently, the receiver just switches to the new frame. You could add
>     some more lines of code to make a better decision. Without adding much
>     complexity you could use the power level to decide.
>     Note that only because you hit these lines of code doesn't mean that
>     frames actually interfered. At this stage the receiver doesn't know how
>     long the frame is and just copies samples corresponding to a
>     maximum-sized frame.
> 
>     Best,
>     Bastian
> 
> 
>     >
>     > On Apr 12, 2017 3:53 PM, "Marcus Müller" <address@hidden
>     <mailto:address@hidden>
>     > <mailto:address@hidden
>     <mailto:address@hidden>>> wrote:
>     >
>     >     Hi Nikita,
>     >
>     >     I'll jump into the general_work method here, directly:
>     >
>     >
>     >       switch(d_state) {
>     >       case SEARCH: {
>     >               int i;
>     >               for(i = 0; i < ninput; i++) {
>     >                       if(in_cor[i] > d_threshold) {
>     >                               if(d_plateau < MIN_PLATEAU) {
>     >                                       d_plateau++;
>     >
>     >                               } else {
>     >                                       d_state = COPY;
>     >     …                                 break;
>     >                               }
>     >     …         }
>     >               consume_each(i);
>     >               return 0;
>     >       }
>     >       case COPY: {
>     >               int o = 0;
>     >               while( o < ninput && o < noutput && d_copied <
>     MAX_SAMPLES) {
>     >                       if(in_cor[o] > d_threshold) {
>     >                               if(d_plateau < MIN_PLATEAU) {
>     >                                       d_plateau++;
>     >
>     >                               // there's another frame
>     >                               } else if(d_copied > MIN_GAP) {
>     >                                       d_copied = 0;
>     >                                       d_plateau = 0;
>     >     …                                 break;
>     >                               }
>     >     …
>     >                       out[o] = in[o] * exp(gr_complex(0,
>     -d_freq_offset * d_copied));
>     >                       o++;
>     >                       d_copied++;
>     >               }
>     >
>     >               if(d_copied == MAX_SAMPLES) {
>     >                       d_state = SEARCH;
>     >               }
>     >     …
>     >               consume_each(o);
>     >               return o;
>     >       }
>     >       }
>     >
>     >     So, this is a pretty classical state machine approach: at
>     every call
>     >     of general_work, the block is in either the COPY or the SEARCH
>     >     state. We only care about whether COPY also does a search
>     operation,
>     >     and, lo:
>     >
>     >                       if(d_plateau < MIN_PLATEAU) {
>     >                                       d_plateau++;
>     >
>     >                               // there's another frame
>     >                               } else if(d_copied > MIN_GAP) {
>     >                                       d_copied = 0;
>     >                                       d_plateau = 0;
>     >
>     >     is exactly that.
>     >
>     >     Best regards,
>     >     Marcus
>     >
>     >
>     >     On 12.04.2017 12:12, Nikita Airee wrote:
>     >>     Hello everyone,
>     >>
>     >>     I was trying to understand how the synchronization in
>     >>     gr-ieee802-11 actually works and went through:
>     >>
>     >>     Bastian Bloessl, Michele Segata, Christoph Sommer and Falko
>     >>     Dressler, "An IEEE 802.11a/g/p OFDM Receiver for GNU Radio"
>     >>
>     >>     However, it seems that the Short Sync and many other blocks have
>     >>     developed further since then.
>     >>
>     >>     From what I understand, the current sync_short.cc does the
>     following:
>     >>
>     >>     1) searches for the peak normalized correlator o/p and compares
>     >>     with the set threshold
>     >>     2) as enough number of simultaneous peaks are detected in
>     >>     correlator o/p, it moves onto the copy stage
>     >>
>     >>     Here is where my doubt lies. Does the block keep looking for new
>     >>     frames while the old one is being copied? Also, what is MIN_GAP's
>     >>     function in the code and how is its value decided upon?
>     >>
>     >>     Could you please clear up these doubts a little?
>     >>
>     >>     Bests,
>     >>     Nikita Airee
>     >>
>     >>
>     >>
>     >>
>     >>     _______________________________________________
>     >>     Discuss-gnuradio mailing list
>     >>     address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>     >>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>     >
>     >
>     >     _______________________________________________
>     >     Discuss-gnuradio mailing list
>     >     address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>     >     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>     >
>     >
>     >
>     > _______________________________________________
>     > Discuss-gnuradio mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>     >
>