|
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<address@hidden> 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&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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin
GitHub/Twitter: @bastibl
https://www.bastibl.net/
|