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