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