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

[Sumit Kumar]

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 that 
to decode the SIGNAL filed. The decision is used to decode both the 
branches. As of now it works, I mean doesn't crash at all! *




*Could you comment on this configuration.

Regards

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 50, 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

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

[Bastian Bloessl]

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 the general_work in sync_long.cc, *ninput* is computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);* 


That's a bit a confusing way to write it, but I guess it's OK.

You'd do it similarly also in Sync Long but also keep the 8192. You 
could check if there's a better min-function that accepts a variable 
number of arguments.


Best,
Bastian




Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
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 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


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 

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

[Sumit Kumar]

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 computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);*


Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
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 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


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=youtu.be
Sumit


On 27/04/2018 10:41, 

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

[Bastian Bloessl]

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 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
     mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
     const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
     add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed to 
the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making it 
difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian


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=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 

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

[Jeff Long]

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 two ports. I also copied the tags to the other 
port too.


In this way it works flawlessly. So your indication that the two 
branches are drifting, seems the correct reason. So how do I solve this ?


I have a solution in my head (based on my understanding... pl correct me).

Following is the current structure where the two LONG_SYNC are working 
independently from each other. Hence ports *C and D *wont guarantee same 
number of *nitems_written.




*Following is the proposed one where I am thinking to combine the 
LONG_SYNC of the two branches in a single inside a single general_work. 
In this way the long_sync block will be forced to produce same number of 
items on both the ports.



**
I did a small testing by creating two output ports on existing long_sync 
block where I just copied the output-1 to output-2. I also copied the 
tags of one branch to the other.
Then connected output-1 to one branch and output-2 to another branch for 
further steps of processing and it worked flawlessly.


I monitored nitems_written(0) and nitems_written(1), and they were 
always same.


Let me know your views on this.

On 30/04/2018 04:23, Jeff Long wrote:
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 does.


You could also disable one of the branches between "sync_short" and 
"add". If it locks up with both branches enable, but not with one 
disabled, then the two branches are probably drifting apart in samples.


Good luck.

On 04/29/2018 01:39 PM, Sumit Kumar wrote:

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 
general_work, that they won't output the same number of bytes."*


Regards

Sumit


On 29/04/2018 18:17, Jeff Long wrote:
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" in them, and the blocks use general_work, that they won't 
output the same number of bytes. But, I'm not familiar with what 
you're trying to do, and haven't played with the 80211 code.


On 04/29/2018 10:10 AM, Sumit Kumar wrote:

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


On 29/04/2018 15:49, Jeff Long wrote:
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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on 
both the branches by calling a modified *insert_tag *function as 
follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % 
item % input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag 
branch -2**

**

*}*

*freq_offset* for both the branches are computed independently 
too. *

*

The dual channel short sync block outputs two streams which are 
fed to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with 
USRP it works good. But after some time, say 2-3 minutes 

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

[Jeff Long]

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 does.


You could also disable one of the branches between "sync_short" and 
"add". If it locks up with both branches enable, but not with one 
disabled, then the two branches are probably drifting apart in samples.


Good luck.

On 04/29/2018 01:39 PM, Sumit Kumar wrote:

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 
general_work, that they won't output the same number of bytes."*


Regards

Sumit


On 29/04/2018 18:17, Jeff Long wrote:
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" 
in them, and the blocks use general_work, that they won't output the 
same number of bytes. But, I'm not familiar with what you're trying to 
do, and haven't played with the 80211 code.


On 04/29/2018 10:10 AM, Sumit Kumar wrote:

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


On 29/04/2018 15:49, Jeff Long wrote:
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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on 
both the branches by calling a modified *insert_tag *function as 
follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item 
% input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch 
-2**

**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP 
it works good. But after some time, say 2-3 minutes or so, USRP 
stops receiving signal. There is no warning or error or overruns 
etc making it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do 
it at a later stage, i.e., do frame detection and synchronization 
in each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine 
correlations values. In essence, you have to make sure that all 
branches start the synchronization process if one branch detects a 
frame.


Best,
Bastian


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 

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

[Sumit Kumar]

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 
general_work, that they won't output the same number of bytes."*


Regards

Sumit


On 29/04/2018 18:17, Jeff Long wrote:
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" 
in them, and the blocks use general_work, that they won't output the 
same number of bytes. But, I'm not familiar with what you're trying to 
do, and haven't played with the 80211 code.


On 04/29/2018 10:10 AM, Sumit Kumar wrote:

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


On 29/04/2018 15:49, Jeff Long wrote:
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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on 
both the branches by calling a modified *insert_tag *function as 
follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item 
% input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch 
-2**

**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP 
it works good. But after some time, say 2-3 minutes or so, USRP 
stops receiving signal. There is no warning or error or overruns 
etc making it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do 
it at a later stage, i.e., do frame detection and synchronization 
in each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine 
correlations values. In essence, you have to make sure that all 
branches start the synchronization process if one branch detects a 
frame.


Best,
Bastian


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.

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

[Jeff Long]

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" 
in them, and the blocks use general_work, that they won't output the 
same number of bytes. But, I'm not familiar with what you're trying to 
do, and haven't played with the 80211 code.


On 04/29/2018 10:10 AM, Sumit Kumar wrote:

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


On 29/04/2018 15:49, Jeff Long wrote:
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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


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=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 

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

[Sumit Kumar]

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


On 29/04/2018 15:49, Jeff Long wrote:
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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


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=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 

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

[Jeff Long]

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 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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
     mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
     const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
     add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed to 
the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making it 
difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian


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=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 50, warnings of buffer over flow kept coming.

Then I used USRP, it 

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

[Sumit Kumar]

"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 synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
    mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
    const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
    add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed to 
the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making it 
difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

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 your view on this.

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian


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=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 50, 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 

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

[Bastian Bloessl]

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 your view on this. 

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian

> 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=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 50, 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 
>> 
> 
 
>>> 
>> 
> 

--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Muhammad Nabeel]

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  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=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 50, 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

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

[Sumit Kumar]

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=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 50, 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

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

[Bastian Bloessl]

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=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 50, 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









--
Dipl.-Inform. Bastian Bloessl
Researcher @ CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Sumit Kumar]

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=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 50, 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

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

[Bastian Bloessl]

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 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 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 50, 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







--
Dipl.-Inform. Bastian Bloessl
Researcher @ CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Sumit Kumar]

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 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 50, 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

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

[Bastian Bloessl]

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 50, 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



--
Dipl.-Inform. Bastian Bloessl
Researcher @ CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio