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
