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
|