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.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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment