"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 <[email protected]> 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) < > [email protected]> 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 < >> [email protected]> 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) <[email protected]> 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 >>>> > [email protected] >>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
