Marcus: Yes, but he computes a sum of N power figures (for N samples), so for it to be 0, there should be N consecutive 0 samples, so the statistics are lower. Looking at the source code, he uses N == 1024.
On Sat, Mar 31, 2018 at 8:28 AM Gilad Beeri (ApolloShield) < gi...@apolloshield.com> wrote: > "if x != 0" will be translated to a super-speedy test both in C++ and in > Python. It is almost guaranteed that your flowgraph bottleneck will be in > another place. My suggestion will be to just add this if statement and to > think about it again only if you prove this is a bottleneck you want to > optimize. > > Regarding your flowgraph vs. unit test question, I think you're right (you > have a flowgraph also in the unit tests). > > > On Sat, Mar 31, 2018 at 8:18 AM Anshul Thakur <anshultha...@rediffmail.com> > wrote: > >> Hi Gilad, >> >> You are correct about getting zeros when using history and I am using >> history. But, I am accounting for that by using the offset: >> >> const gr_complex *current = (const gr_complex *)&((const gr_complex >> *)input_items[0])[(history() -1)]; >> >> Also, if that is the case, shouldn't the behaviour be consistent across >> unit-tests and flowgraph usage? >> >> Regarding getting 0s from the device, I went through the discussion. I >> agree to it. So, I'll have to account for the zero values. Any ideas on how >> to do that? >> >> The reason why I don't want to use an 'if' block is simply because the >> situation of 0 values is expected to share a very small fraction of the >> entire run and >> to handle that small case, the regular cases will also necessarily have >> to go through that additional 'if' check. I wanted to avoid that. >> >> Regards, >> Anshul >> >> On 31 March 2018 at 10:37, Gilad Beeri (ApolloShield) < >> gi...@apolloshield.com> wrote: >> >>> Disclosure: I haven't looked at your code. >>> >>> 0 values can be presented in GNU Radio when you use history, because if >>> your history is N, the first N-1 items are going to be zeros. >>> >>> Anyway, regarding your comment "it is not expected that a device/stream >>> would ever spit out zero values.", >>> I did have 0 values from a USRP device, see discussion in >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html >>> . >>> >>> >>> >>> On Sat, Mar 31, 2018 at 6:52 AM Anshul Thakur < >>> anshultha...@rediffmail.com> wrote: >>> >>>> Michael, Marcus, >>>> >>>> Right now, the code is a work in progress so I haven't made a git >>>> repository out of it. However, I have it on dropbox. Here's the link to the >>>> source folder(p1_detector_impl.cc is the source in question): >>>> >>>> *https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0 >>>> <https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0>* >>>> >>>> As for Marcus's question regarding why use a circular buffer? >>>> >>>> It isn't exactly a circular buffer now, but more of a shift register. >>>> The reasons are as follows: >>>> 1. I needed running sums for correlations in B-Branch and C-Branch >>>> correlators, and Power Sums (for average power) to normalize them. Then, I >>>> also needed a finite delay buffer to delay the C-Branch before it gets >>>> multiplied with the B-Branch. >>>> 2. It kind of carried over from the last implementation attempt: >>>> >>>> Assertion: If a peak is detected after the multiplication, the signal >>>> boundary is 1024 samples behind that index. >>>> >>>> Once the correlations crossed a threshold (the code entered state=1), >>>> *instead >>>> of looking back, I then needed to look forward to see if it were a false >>>> alarm or not*. So, I compute the correlations across all available >>>> current inputs and try to find a peak. If a peak is found, enter state=3 >>>> where we do a correlation with the carrier distribution sequence after FFT >>>> of all signals of interest. So, here, I not only needed just the single >>>> value (the running sum), but the entire state of the delay register and the >>>> B-Branch correlator. >>>> >>>> I hope I am able to convey the reason for implementing one myself. >>>> >>>> In the current implementation, I make an assumption that the threshold >>>> is so high that only the desired signals would cross it (100-150 times the >>>> average). So I skip the state=1 logic and directly go into state=2 logic of >>>> aggressively doing a FFT and correlation with the CDS. >>>> >>>> However, I don't think this has a binding on the incoming values. Use >>>> of buffers is internal to the implementation, I am just printing out the >>>> current values as they arrive. >>>> >>>> For example, when I use the test file in 'make test', the values fed in >>>> are non-zero from t=1. However, when using gnuradio-companion, t=56 line is >>>> where the file source starts yielding proper inputs to my block. The stdout >>>> prints of the initial values in both GRC and make tests are attached. The >>>> gnuradio-companion version has my first 55 samples zeroed and the 56th >>>> input onward is then same for both. >>>> >>>> >>>> P.S.: The source stream is a 1.2 Gigs file, so haven't uploaded it. If >>>> you'd like I can do that too. It was generated by using a DVB-T2 Tx block >>>> and writing the output into a file sink. >>>> >>>> Warm regards, >>>> Anshul Thakur >>>> >>>> On 31 March 2018 at 02:27, Müller, Marcus (CEL) <muel...@kit.edu> >>>> wrote: >>>> >>>>> Hi Anshul, >>>>> >>>>> you shouldn't have to have your own buffer for a running sum – can you >>>>> explain why you're doing that? >>>>> A running sum can trivially be implemented with the IIR filter block >>>>> with Feed-Forward taps (1,) and Feed-back taps (1,0)! >>>>> Where does in a running sum does a division take place? >>>>> >>>>> > (a) Why am I getting the initial zero samples from the file block in >>>>> > gnuradio_companion and non-zero values when using a vector_source in >>>>> > unit tests? >>>>> >>>>> If these zeros are not in the file you're reading, your block has a >>>>> bug! >>>>> >>>>> >>>>> > (b) What can I do about it (here specifically as a fix to the >>>>> > situation, and a general guideline to always remember)? >>>>> >>>>> good question, but we'd need to know your code, your motivation for a >>>>> circular buffer, and why you're implementing a running sum yourself! >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> On Fri, 2018-03-30 at 23:19 +0530, Anshul Thakur wrote: >>>>> > Hi, >>>>> > >>>>> > I used a circular buffer of finite size to keep the past 'N' power >>>>> > values of the sample stream in my block as a part of creating a >>>>> > running sum. This buffer is initialized to 0 in the constructor. >>>>> > The running sum of powers is used to compute the average power used >>>>> > in computing signal correlation. >>>>> > >>>>> > I have a capture stream (cfile) to test the operation of the block. >>>>> > The test case uses a vector_source_c block to read the contents of >>>>> > the file into memory. The unit tests pass without error. >>>>> > >>>>> > However, when I use the block in a flowgraph in that reads the same >>>>> > file from a file source block gnuradio_companion, I am getting the >>>>> > first few sample values as 0 which cause a divide by zero >>>>> > problem. This messes up the rest of the running sum. I don't want to >>>>> > put an 'if' block that checks for the zero condition as it is not >>>>> > expected that a device/stream would ever spit out zero values. >>>>> > >>>>> > (a) Why am I getting the initial zero samples from the file block in >>>>> > gnuradio_companion and non-zero values when using a vector_source in >>>>> > unit tests? >>>>> > >>>>> > (b) What can I do about it (here specifically as a fix to the >>>>> > situation, and a general guideline to always remember)? >>>>> > >>>>> > I am using GNURadio version 3.7.12. >>>>> > >>>>> > Regards, >>>>> > Anshul >>>>> > _______________________________________________ >>>>> > 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
