Hi all, finally I added only delay of 64 samples due to correlate access code and it works good. My filter is of order 165 and with that additional delay the rssi is wrong. Why there is no delay due to the filter?
Thank you On Fri, Jul 19, 2013 at 12:05 AM, Nemanja Savic <vlasi...@gmail.com> wrote: > Hi Adeel, all, > > thank you again for your reply. > The structure of my receiver is following: > > /---> filter ---> quadrature demod ----> threshold > detector ---> clock synchronization ---> correlate ac ---> deframer > usrp source > / > / > > \ > / > \---> rms ---> 10 log > ----------------------------------------------------------------/ > > Inside clock synchronization block stream is "broken" it might be that I > am not able to determine where the actual burst started (maybe roughly) and > that's why I want to send information about rssi together with every symbol > value (i will think about idea to use 6 upper unused bits to put rssi > inside). > With current configuration it looks like the only delay I need to > calculate is due to filter at the begining? (all other blocks should not > introduce any delay). What should I do in order to get the order of filter? > > Best, > Nemanja > > > On Thu, Jul 18, 2013 at 5:50 PM, Adeel Anwar <adeela...@gmail.com> wrote: > >> Nemanja, >> >> >> >>The problem that I have now is how to ensure that samples from >> demodulator chain and samples from RSSi calculator come in the same time to >> the symbol decision block. How can I tune this delay and is it >> deterministic? >> Yes, the delay is fix and can be determined by adding delay of all >> "Filters" in Rx-chain. Moreover IIRC, corrrelate-access-code itself adds >> 64bits delay that u need to cater for in ur custom block. >> >> >> >> On every symbol I read RSSI and send that value forward. As soon as I >> detect premble i start calculating RSSi for the packet based on number of >> symbols >> I will suggest that donot calculate RSSI for every symbol instead >> calculate RSSI for complete packet >> >> -Adeel >> >> >> On Thu, Jul 18, 2013 at 8:05 PM, Nemanja Savic <vlasi...@gmail.com>wrote: >> >>> Hi, >>> >>> thank you Adeel for your answer. I implemented almost the same approach >>> yesterday. I bring signal from USRP through rms and log calculator directly >>> to the block for sampling symbol value. On every symbol I read RSSI and >>> send that value forward. As soon as I detect premble i start calculating >>> RSSi for the packet based on number of symbols. >>> The problem that I have now is how to ensure that samples from >>> demodulator chain and samples from RSSi calculator come in the same time to >>> the symbol decision block. How can I tune this delay and is it >>> deterministic? >>> >>> Many thanks, >>> Nemanja >>> >>> >>> On Thu, Jul 18, 2013 at 2:33 AM, Adeel Anwar <adeela...@gmail.com>wrote: >>> >>>> Nemanja, >>>> >>>> I built this block sometime back. The ideas is to construct a custom >>>> RSSI Measurement block having input >>>> >>>> 1: complex IQ-samples after USRP-SRC or before "AGC" >>>> 2: byte-stream after "digital_correlate_access_code_bb". Output byte >>>> stream has data in LSB (1st bit) while Flag in 2nd bit shows header >>>> detection) >>>> 3: Calculate system/filters group-delay between the complex-IQ samples >>>> stream and output-of-correlate-access-code. This delay will depend on the >>>> a) No. of filters in system e.g. FLL-Filter, PFB-Timing-Synch etc >>>> b) No. of filter Taps >>>> 3: Delay the complex IQ-samples stream by amount calculated in 3 >>>> 4: In Custom RSSI-Measurement Block use following logic >>>> if (2-bit of correlate-access-code-stream) is High: >>>> Take average of N-items from IQ-samples stream >>>> >>>> where "N" depends on >>>> a) No of symbol in packet >>>> b) Samples-per-Symbol >>>> >>>> Hope this helps >>>> >>>> -Adeel >>>> >>>> >>>> >>>> On Wed, Jul 17, 2013 at 12:36 AM, Nemanja Savic <vlasi...@gmail.com>wrote: >>>> >>>>> This looks a bit silly cause I am speaking with myself. Anyway, maybe >>>>> I can do something with probe_avg_mag_sqr, but maybe somebody can tell me >>>>> how can I access that block's values from another block? >>>>> >>>>> Best, >>>>> Nemanja >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 3:16 PM, Nemanja Savic <vlasi...@gmail.com>wrote: >>>>> >>>>>> The only way that is on my mind is to detect burst and store it in a >>>>>> file, and then to send a message to the block that will read that file, >>>>>> and >>>>>> in case of successfull demodulation and decoding to calcualte signal >>>>>> power, >>>>>> but it looks pretty robust and non elegant. >>>>>> >>>>>> Cheers, >>>>>> Nemanja >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 2:26 PM, Nemanja Savic <vlasi...@gmail.com>wrote: >>>>>> >>>>>>> Any suggestions on this topic, opinions? >>>>>>> >>>>>>> Best >>>>>>> Nemanja >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 9, 2013 at 4:23 PM, Nemanja Savic <vlasi...@gmail.com>wrote: >>>>>>> >>>>>>>> Hi again gnuradioers, >>>>>>>> >>>>>>>> as always, I would like to ask for your opinion before starting to >>>>>>>> write my own block. >>>>>>>> Basically, I would like to add a feature to my receiver to be able >>>>>>>> to calculate average signal strength during signal reception. When I >>>>>>>> receive a valid packet I would like to have a RSS value. My >>>>>>>> question is what is the best way to accomplish this in GNURADIO? >>>>>>>> Using tags or messages, ...? IS there anything similar already >>>>>>>> provided so >>>>>>>> that I can take a look? >>>>>>>> >>>>>>>> Thank you and best >>>>>>>> >>>>>>>> -- >>>>>>>> Nemanja Savić >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nemanja Savić >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nemanja Savić >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nemanja Savić >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>> >>> >>> -- >>> Nemanja Savić >>> >> >> > > > -- > Nemanja Savić > -- Nemanja Savić
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
