On 03/31/2018 01:18 AM, Anshul Thakur 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
Assuming that your input voltages are uniformly distributed about zero,
and we'll say for the sake of argument that we're talking a 12-bit sampler,
and we model the input as a purely-random process (it isn't of
course) then the density of numerical zeros will be about 1/2048 in the
data stream.
That's a lot of zeros.
On 31 March 2018 at 10:37, Gilad Beeri (ApolloShield)
<gi...@apolloshield.com <mailto: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
<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 <mailto: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 <mailto: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 <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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
