On 03/31/2018 01:07 AM, Gilad Beeri (ApolloShield) 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.
Why would a hardware device *NOT* occasionally spit-out exactly-zero
values? These devices are measuring instantaneous, AC-voltage samples
at the antenna port (or a proxy for 'at the antenna port'). Ignoring
DC-offset for a moment, some fraction of those samples will be 0s, since
they
are AC voltages that swing between negative-some-voltage and
positive-some-voltage, and the ADC must necessarily quantize this into
bits, there will *absolutely* be values that are exactly zero, and
completely "legitimate".
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_
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto: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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
