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" <[email protected]> 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" <[email protected] > > <mailto:[email protected]>> 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 > >> [email protected] <mailto:[email protected]> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] <mailto:[email protected]> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
