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<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/
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|