Hi, As Basti pointed out, you are basically missing the synchronization logic between branches.
You have to detect the signal in all branches and have to come up with a logical block which could synchronize them all, right before addition. This issue does not arises in simulations because these branches are perfectly synchronized within one flowgraph, however, when you use USRPs, there is no guarantee that the signals will be automatically synchronized due to a presence of real channel. Best regards, Muhammad Nabeel On Sat, Apr 28, 2018 at 5:02 PM, Sumit Kumar <sumit.ku...@eurecom.fr> wrote: > Following your article "An IEEE 802.11a/g/p OFDM Receiver for GNU Radio" , > I plan to add > > a[n] (as in Eq-1) from the two antenna branches. Also add p[n] (as in > Eq-2) from two antenna branches. > > Finally use them as numerator and denominator respectively for Eq-3. > > So basically I will be combining the correlation values from all antennas > to find the start of WiFi frame. With this approach, I believe, there wont > be any need of synchronization between branches. Let me know your view on > this. > Regards > > Sumit > > > > On 27/04/2018 11:25, Bastian Bloessl wrote: > > I don't know about such an implementation. IIRC, in the paper, we recorded > the IQ samples and processed the data offline. > > If you are interested in the code you could write the first author, but > since it was not real-time and for a single-carrier scheme, it might not be > too helpful for your project. > > If you come up with a solution, let me know. > > Best, > Bastian > > > On 04/27/2018 11:15 AM, Sumit Kumar wrote: > > Ok I understand now. Could you point me how to approach for such > synchronization between the two branches. Or if there are any existing open > source example if you know. > > For this implementation, I was following one of your recently co-authored > paper "Low-Complexity Soft-Bit Diversity Combining for Ultra-Low Power > Wildlife Monitoring". However it seems that the source code is not open > yet. > > Sumit > > > On 27/04/2018 11:00, Sumit Kumar wrote: > > Yes indeed, this could also happen! I note this in my to-do list. > > But as of now there are no warnings of overruns etc. I recorded it. What > is making USRP to stop receiving. > > https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be > > Sumit > > > On 27/04/2018 10:41, Bastian Bloessl wrote: > > Hi, > > I'm not sure if I get it, but don't you need some synchronization logic > between the branches. Consider what happens if one branch receives frames > while the other one doesn't, then data queues up in the add block, which > will sooner or later lead to overruns, independent from the buffer size. > > Best, > Bastian > > On 04/27/2018 09:54 AM, Sumit Kumar wrote: > > Hi, > > I am working on soft bit maximal ratio combiner (SBMRC). It's basically a > MRC but instead of combining the actual signals according to their SNR, we > combine the LLRs from separate branches and send them to Soft Decision > Viterbi Decoder (SDVD). For this, I have modified gr-ieee 80211 which > generates soft bits and integrated a SDVD with it. It works good when I use > either single branch or both branch separately. > > In order to implement SBMRC, for every OFDM symbol decoded, a vector of > LLR (size 48 X 1) is generated from both the receiver branches. These two > vectors of LLR are further added and sent to SDVD. I configured the ADD > block to take 48 floats as input. > > First I made a simulator for SBMRC, but even after increasing the output > buffer size to 500000, warnings of buffer over flow kept coming. > > Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx A > and Tx/Rx B ports as my receive branches. The LEDs go green for a second > then stop. No error no warning. > > Looks like the *ADD *block is the cause. I have never seen this, so I am > clueless where to debug. Am I missing something fundamental here ? > > The attached picture *usrp_sbmrc* says details of my schematic and the > results when I use USRP. > > The attached picture *sbmrc_sim* says details of my schematic and the > results when I use simulations. > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
