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<sumit.ku...@eurecom.fr> 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
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/
--
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
