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

[Nikita Airee]

Hi again, a few quick questions.

How do you decide on the values of MIN_GAP(480) and Max frame size(540*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?

Bests, 

Nikita

On Apr 12, 2017 9:38 PM, "Bastian Bloessl" <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@hiddencom>> 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@hiddenorg>
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hiddenorg>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>