discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being ze


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being zero.
Date: Sat, 31 Mar 2018 01:43:12 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 03/31/2018 01:35 AM, Gilad Beeri (ApolloShield) wrote:
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.


Sure, but not infinitely so.

Herr Mueller already pointed out why division in DSP flows is tricky, and hardly ever used.  Dealing with the INFINITY case is one of those reasons.



On Sat, Mar 31, 2018 at 8:28 AM Gilad Beeri (ApolloShield) <address@hidden> 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 <address@hidden> 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) <address@hidden> 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 <address@hidden> 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

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) <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]