Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi bastian, To solve the following issue (as you predicted): *"Consider what happens if one branch receives frames while the other one doesn't,Consider what happens if one branch receives frames while the other one doesn't." *I combine the LLR of the SIGNAL fields from two branches and use

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi, On 05/02/2018 12:04 PM, Sumit Kumar wrote: Hi Bastian, Yes thats correct. I believe this problem will be there if I do soft bit MRC i.e. independent decoding of the two branches. Just combining the long sync is not the solution :( On an other note I have following question : Inside

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi Bastian, Yes thats correct. I believe this problem will be there if I do soft bit MRC i.e. independent decoding of the two branches. Just combining the long sync is not the solution :( On an other note I have following question : Inside the general_work in sync_long.cc, *ninput* is

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

The problem with this configuration is that the "Soft frame equalizer" blocks are not synced. It's the same problem as with the Sync Short block, just at a later stage. Consider what happens, if one branch manages to decode the signal field and one doesn't. Or one thinks it's a 100 Byte BPSK

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Glad I could help out with the plumbing part of the problem, but I think you'll need someone who knows how the wifi code works to help you out now. On 04/30/2018 12:55 PM, Sumit Kumar wrote: Hi Jeff, Ok Now I did some experiments. I modified the long_sync block where it outputs same items on

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

You are looking for the number of samples written by the two sync_long blocks to drift apart over time. When the flowgraph locks up, see what the difference is. There's a bit too much logic in this file for me to take a quick look and say whether i and o differ, but there are hints that it

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi Jeff, Ok now I print nitems_written(portnum) after every general_work call. But what should I check for. ( I am sorry, I never did such debugs before. ) Can you please explain this in a little more detail *"you have 2 parallel paths with the word "sync" in them, and the blocks use

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

If you can get the ctrlport monitor/profiling code working (I can't at the moment), you can watch the buffers fill. Or, you could have the sync_long blocks print out nitems_written(portnum) after every general_work call. It seems likely that if you have 2 parallel paths with the word "sync"

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi Jeff, Ok I understand that. But how to verify this lock-up ? Similar to dual_channel short sync if I make a new block i .e dual channel long sync, will it force this block to produce same number of outputs on two output ports ? I am attaching the grc file for reference. Regards Sumit

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

I don't know the 802.11 code, but if the 2 sync_long blocks produce different amounts of output, eventually the "add" block will lock up. On 04/29/2018 09:30 AM, Sumit Kumar wrote: "In essence, you have to make sure that all branches start the synchronization process if one branch detects a

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

"In essence, you have to make sure that all branches start the synchronization process if one branch detects a frame." I am doing only slightly different from above. Frame detection is happening with the combined value of correlation. And once frame is detected, both of the branches start the

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Hi, > On 28. Apr 2018, at 17:02, Sumit Kumar wrote: > 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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

Not sure what this video shows, but I guess that's the same thing. If one queue of the add block is full (and the other is empty) then, I guess, the flow graph is stuck and the USRP will stop receiving. On 04/27/2018 11:00 AM, Sumit Kumar wrote: Yes indeed, this could also happen! I note this

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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=youtu.be Sumit On 27/04/2018 10:41, Bastian Bloessl wrote: Hi, I'm not

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

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