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.kumar@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
No comments:
Post a Comment