[Discuss-gnuradio] Peak_Detector2 stalls simulation

[Achilleas Anastasopoulos]

Stephan,

We have worked with this block and realized it has a bug (not just an
inefficient functionality).
This is easy to see if you consider what happens when the first time work
is called, the threshold is passed,
a peak is found in item "i" and so  "d_peak_ind" is set to "i",
but there are less that d_lookahead_items to be processed.
Then suppose the second time the work is called, no other peak is found and
d_lookahead_remaining goes to 0.
Then the output buffer will be accessed at:
"optr[d_peak_ind] = 1" which may not even be a valid access since the value
of d_peak_ind was set to "i"
in the previous work call!

Anyway, I attach a fix to this (we were supposed to post it sooner on the
list but got delayed by some other issues).
Please note that in this current form the functionality is a bit different
than the one suggested in the manual, ie,
the peak finder ONLY looks ahead d_lookahead items from the point the
threshold is crossed, but it does not
reset this window every time a new peak is found within the window.
It should be pretty easy to do this as well...

Please let us know if you have any comments.

best
Achilleas


peak_detector2_fb_impl.cc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting time each time power squelch is on

[Dan CaJacob]

Hi Luis,

I am pretty certain there is a block in mainline GR to do this with
tagging.  Burst tagger maybe?  The tags define the burst boundaries and a
timestamp is recorded as well.
 On Jan 2, 2015 5:46 PM, "Luis Colunga"  wrote:

> Hello,
>
> I have a Python handcoded block in which I want every time that power
> squelch is triggered, grab the actual time and then use that filename
> to write a wav file with a decoded stream.
>
> What would be a good approach? I tried using variables but I see they
> don't update at runtime and I am not sure if you are able to change
> the wav sink name on runtime and just expect it to work or if it
> neccesary to do something else there.
>
> Thanks.
>
> ___
> 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

[Discuss-gnuradio] Getting time each time power squelch is on

[Luis Colunga]

Hello,

I have a Python handcoded block in which I want every time that power
squelch is triggered, grab the actual time and then use that filename
to write a wav file with a decoded stream.

What would be a good approach? I tried using variables but I see they
don't update at runtime and I am not sure if you are able to change
the wav sink name on runtime and just expect it to work or if it
neccesary to do something else there.

Thanks.

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

[Discuss-gnuradio] optional port in grc block

[Achilleas Anastasopoulos]

Hi all,

I would like to have grc block with a bool option "Debug".
Once this is set to True, then I would like to have an additional output
port.

How do I do that?

I already added this part in the xml file:


Debug
debug
False
bool
 

but now I don't know how to use this variable to make the additional port
appear
in the block.


thanks
Achilleas


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

Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Andy Walls]

On Fri, 2015-01-02 at 09:56 -0800, Nick Foster wrote:

> 
> There is another problem which prevents proper correlation:
> the end of
> work coming mid-burst.  See the attached "End of work
> mid-corr.png"
> which shows an end of work tag with the value of
> noutput_items.  I'm not
> sure how to handle this is the general case, except for burst
> energy
> detection.  But burst energy detection won't work for
> CDMA-like things,
> where the signal might be buried in the noise.
> 
> 
> I'm in the middle of generalizing correlate_and_sync_cc to allow use
> with any candidate vector you want (although I hadn't considered the
> real-only case). It's working now, and just this morning I encountered
> the same thing you're seeing. Of interest to me is the loop:
> 
> 
> <...>
> d_filter->filter(noutput_items, in, corr);
> <...>
> int i = d_sps;
> while(i <...>
> 
> 
> ...with set_history(d_filter->ntaps()) in the constructor, we should
> probably be running the filter against the entire input vector
> including history, and copying to the output the part relevant to the
> current work call. Or, only running the work function up to
> (noutput_items - d_filter->ntaps()) items. Right?
> 
> 
> --n

I haven't worked through all that yet, myself. :)

I do know with my differential input signal, I have to run the
subtraction through all the history and the output items to get the
proper baseband input vector.  Here's what I'm doing currently in that
start of work():

memcpy(out_p, in_p, sizeof(float)*noutput_items);
memcpy(out_n, in_n, sizeof(float)*noutput_items);

// Compute the unequalized baseband input
volk_32f_x2_subtract_32f(d_in, in_p, in_n, noutput_items + 
(history()-1));

// Calculate the correlation with the known symbols
d_filter->filter(noutput_items, d_in, corr);

I was *assuming* the d_filter->filter() call was sucking in the proper
amount of history it need for noutput_items based on d_filter->ntaps()
since it already knows ntaps().

My possibly flawed understanding of history() is that the actual size of
the incoming buffer is at least noutput_items + (history()-1), and that
in[0] points to the oldest sample in the history.

I thought the discontinuity in the output of the correlation at the
beginning of the next work call looked odd.   So maybe I've got
something wrong. 

-Andy



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

Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Nick Foster]

>
>
>
> Hi Tom,
>
>
> > Andy,
> >
> >
> > Thanks for the reports and details. I can definitely see the problem
> > with the situation you're describing. We obviously weren't considering
> > that case when we designed the block. We were really expecting any
> > preamble/access code that we were using would have good
> > autocorrelation statistics. From that perspective, the 10101...
> > pattern is pretty silly, but hey, it is used.
>
> Yeah.
>
> > Right now, you're probably best off redoing your own block as you say
> > to deal with the specifics of your case. However, I'd like us to think
> > about how we can abstract this concept within the current block so
> > that we can more easily provide the behavior we'd like to see, such as
> > the correlation and detection logic, and the filter design. I know
> > Nick Foster has thoughts on this, too, with his work on GMSK signals.
>
> Yes, I leveraged Nick's msk_correlate_and_sync as well. :)
>
> For visualizing the scenario I mentioned, see the attached "Clock
> pattern correlation.png".  I took the "corr" output of my custom block
> and plotted its abs() along with the baseband input. My custom block
> picked the two large positive correlation peaks and ignores the nearby
> negative ones.  With my particular real, baseband input, I'm guaranteed
> not to have any sign ambiguity in the baseband input; so I could ignore
> that wrinkle.
>
> There is another problem which prevents proper correlation: the end of
> work coming mid-burst.  See the attached "End of work mid-corr.png"
> which shows an end of work tag with the value of noutput_items.  I'm not
> sure how to handle this is the general case, except for burst energy
> detection.  But burst energy detection won't work for CDMA-like things,
> where the signal might be buried in the noise.
>

I'm in the middle of generalizing correlate_and_sync_cc to allow use with
any candidate vector you want (although I hadn't considered the real-only
case). It's working now, and just this morning I encountered the same thing
you're seeing. Of interest to me is the loop:

<...>
d_filter->filter(noutput_items, in, corr);
<...>
int i = d_sps;
while(i

...with set_history(d_filter->ntaps()) in the constructor, we should
probably be running the filter against the entire input vector
*including* history,
and copying to the output the part relevant to the current work call. Or,
only running the work function up to (noutput_items - d_filter->ntaps())
items. Right?

--n


>
> Regards,
> Andy
>
>
>
> ___
> 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

[Discuss-gnuradio] Peak_Detector2 stalls simulation

[Ludwig Stephan (CR/AEH4)]

Hello and Season's Greetings,

I am experiencing a  problem with the blocks::peak_detector2 block. The 
simulation stalls after some time. My conjecture is that this is due to the 
kind the block handles its output in work(), but I am not sure, since I am not 
that deep into the scheduler. I am kindly asking for comments and hints on this 
issue.

My System:
Kubuntu 14.10 64 Bit
GNURadio from Git via Pybombs

Consider the attached minimal GRC example for reproducing the problem


[I just changed gnuradio/gr-blocks/grc/blocks_peak_detector2.xml such that the 
additional "averaged value" output port is visible in GRC, i.e. added

 avg_out
float

]

Symptoms:
* With the setup from the minimal example the displayed waves of the 3-input QT 
GUI Time Sink stall.
* If the Peak-Detector and sub-sequent parts are disabled, the simulations 
keeps on running (i.e. does not stall)
* if peak_detector2 is enabled, but its outputs are just connected to null 
sinks, the simulation stalls again.

Conjecture:
* Either the input buffer of Peak Detector2 over-flows or
* not enough output items are produced in order to remain synchronous

Traceback:
I do not have a clue, what is actually malfunctioning, hence I am asking for 
help.

Thoughts:
1) Have a look at gnuradio/gr-blocks/lib/peak_detector2_fb_impl.cc. This is a 
synchronous block and in the ::work(.) function noutput_items is returned (line 
106), if no peak has been detected within the input values. From my 
understanding, once an input value is above the threshold, the block searches 
for the peak within the next look_ahead values. Name this part the "active peak 
search", which is indicated by d_found = true.

If the search continues for more than another call of work(.), I cannot predict 
the blocks behaviour, because I do not know the details of the scheduler, 
especially, where input and especially output indexing starts if no input items 
have been consumed in a previous call of work(.). If a peak is detected 
(d_found = true), all samples being previous to the peak's one are "consumed" 
(line 112: return tmp - 1), and d_peak_ind = 1 is set.

Just for clarification: Does it matter that the allocated memory of 
output_items[0] is noutput_items of size, but a smaller number is returned from 
work(.)? (I do not think so)

In the next call of work(.), the input samples with relative index starting 
from 0 are considered. Because this is a synchronized block (output items = 
returned nr. of "consumed" input items), from my understanding this is the 
peak's sample (index 0, BTW: thus I think d_peak_ind = 0 should have been set 
in the previous function call) and all subsequent ones. If d_found=true at the 
beginning of the function, this would mean that some samples are checked a 
second time. Although this might be inefficient, I do not consider this being 
the root of the problem.

2) The only way not to empty the input buffer is while d_found = true, but then 
input values have to increase within look_ahead.

3) Why is noutput_items >= 2 required (cp. Assert in line 65)?

I haven't got any idea how to proceede from here. Do you have any 
ideas/hints/comments?

Thank you in advance.

Mit freundlichen Grüßen / Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology 
(CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
stephan.ludw...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk 
Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller





teat_peak_search_error.grc
Description: teat_peak_search_error.grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Tom Rondeau]

On Fri, Jan 2, 2015 at 8:57 AM, Andy Walls 
wrote:

> On Wed, 2014-12-31 at 15:48 -0500, Andy Walls wrote:
> > On Wed, 2014-12-31 at 14:00 -0500, Andy Walls wrote:
> > > Hi.
> > >
> > > Can someone give me a brief clue about the threshold testing in the
> > > correlate_and_sync block?
>
> I found my answer in this post:
>
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1310
>
> "The correlation peak is tested by first observing that the width of the
> correlation peak will be sps number of samples wide. So we look at
> sample i and sample (i-sps). If the difference between these two symbols
> is greater than the threashold we calculated in the constructor, we
> declare a correlation."
>
> That probably works for most preambles.
>
> Unfortunately it becomes a problem with the data sequence
> "101010101010..." and a rectangular pulse filter, as the absolute value
> (magnitude) peaks of the correlation increase somewhat linearly as the
> sequences align, and there will be a peak at every sps samples.  Thus
> the threshold test won't trigger as expected.
>
> The correlation absolute value peak happens every sps samples because,
> using NRZ bit mapping (0 => -1, 1 => 1), the positive correlation is
> about as strong as the neighboring negative correlation that is sps
> samples away.
>
> I'm not sure if I should file a bug report for this corner case or not.
>
> I'm writing my own correlator block based on the correlate_and_sync
> block; except that it works on real, not complex, input samples.   For
> myself, I just use the unmodified output of the real valued correlation
> filter and just set the threshold test to be relative to 0.



Andy,

Thanks for the reports and details. I can definitely see the problem with
the situation you're describing. We obviously weren't considering that case
when we designed the block. We were really expecting any preamble/access
code that we were using would have good autocorrelation statistics. From
that perspective, the 10101... pattern is pretty silly, but hey, it is used.

Right now, you're probably best off redoing your own block as you say to
deal with the specifics of your case. However, I'd like us to think about
how we can abstract this concept within the current block so that we can
more easily provide the behavior we'd like to see, such as the correlation
and detection logic, and the filter design. I know Nick Foster has thoughts
on this, too, with his work on GMSK signals.

Tom




> > >
> > > Then in the work function (corr is a totally different array variable
> > > here):
> > >
> > >   // Calculate the correlation with the known symbol
> > >   d_filter->filter(noutput_items, in, corr);
> > >
> > >   // Find the magnitude squared of the correlation
> > >   std::vector corr_mag(noutput_items);
> > >   volk_32fc_magnitude_squared_32f(&corr_mag[0], corr,
> noutput_items);
> > >
> > >   int i = d_sps;
> > >   while(i < noutput_items) {
> > > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {
> > >
> > > This "if" test confuses me slightly.  We check to see if the value of
> > > the output of the matched filtering has crossed the threshold relative
> > > to one symbol previous?  Why not just check relative to 0?
> >
> >
> > An additional note: The "if" test doesn't work too well, if the preamble
> > sequence is "101010101010...", since then the correlation will have
> > peaks at the symbol spacing, d_sps.  Maybe
> >
> >   if((corr_mag[i] - corr_mag[i-d_sps/2]) > d_thresh) {
> >
> > would be better, since the correlation should sag at the half symbol?
>
> Regards,
> Andy
>
>
>
> ___
> 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

Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Andy Walls]

On Wed, 2014-12-31 at 15:48 -0500, Andy Walls wrote:
> On Wed, 2014-12-31 at 14:00 -0500, Andy Walls wrote:
> > Hi.
> > 
> > Can someone give me a brief clue about the threshold testing in the
> > correlate_and_sync block?

I found my answer in this post:

https://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1310

"The correlation peak is tested by first observing that the width of the
correlation peak will be sps number of samples wide. So we look at
sample i and sample (i-sps). If the difference between these two symbols
is greater than the threashold we calculated in the constructor, we
declare a correlation."

That probably works for most preambles.
 
Unfortunately it becomes a problem with the data sequence
"101010101010..." and a rectangular pulse filter, as the absolute value
(magnitude) peaks of the correlation increase somewhat linearly as the
sequences align, and there will be a peak at every sps samples.  Thus
the threshold test won't trigger as expected.

The correlation absolute value peak happens every sps samples because,
using NRZ bit mapping (0 => -1, 1 => 1), the positive correlation is
about as strong as the neighboring negative correlation that is sps
samples away.

I'm not sure if I should file a bug report for this corner case or not.

I'm writing my own correlator block based on the correlate_and_sync
block; except that it works on real, not complex, input samples.   For
myself, I just use the unmodified output of the real valued correlation
filter and just set the threshold test to be relative to 0.

> > 
> > Then in the work function (corr is a totally different array variable
> > here):
> > 
> >   // Calculate the correlation with the known symbol
> >   d_filter->filter(noutput_items, in, corr);
> > 
> >   // Find the magnitude squared of the correlation
> >   std::vector corr_mag(noutput_items);
> >   volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, noutput_items);
> > 
> >   int i = d_sps;
> >   while(i < noutput_items) {
> > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {
> > 
> > This "if" test confuses me slightly.  We check to see if the value of
> > the output of the matched filtering has crossed the threshold relative
> > to one symbol previous?  Why not just check relative to 0?
> 
> 
> An additional note: The "if" test doesn't work too well, if the preamble
> sequence is "101010101010...", since then the correlation will have
> peaks at the symbol spacing, d_sps.  Maybe 
> 
>   if((corr_mag[i] - corr_mag[i-d_sps/2]) > d_thresh) {
> 
> would be better, since the correlation should sag at the half symbol?

Regards,
Andy



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