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 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/
_______________________________________________
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
_______________________________________________
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