Re: [Discuss-gnuradio] debugging for gnuradio DSP programming

[Ernest Fardin]

Hi Linda,

The argument to boost::format() might need to be checked. GR_LOG_DEBUG() is
used in [1], for example.

Cheers,

Ernest


[1] https://github.com/gnuradio/gnuradio/blob/493338d86d82e9
e10f5d9d4b42f2473b7275c7a2/gr-blocks/lib/test_tag_variable_r
ate_ff_impl.cc#L80


On Wed, May 30, 2018 at 11:30 PM, Linda20071  wrote:

> Thanks for your detailed information.
>
> I have done a lot of DSP programming in other environments but not in
> gnuradio. So your wiki page is helpful. The reason I posted the question is
> that, I was unable to get the log output in my screen with the following
> codes in the work function:
>
> {{{
>
>   // Do <+signal processing+>
>   for (int i = 0; i < noutput_items; i++) {
> out[i] = in[i] * in[i];
>int ret = do_some_signal_processing(d_len, [i]);
> if (ret == 0) {
>   GR_LOG_DEBUG(d_logger, boost::format("Detected event on sample
> %l%", i));
> }
>   }
>
>   // Tell runtime system how many output items we produced.
>   return noutput_items;
> }
>
> int
> detector0_impl::do_some_signal_processing(int len, float* out)
> {
> return 0;
> }
>
> }}}
>
> Since every time  do_some_signal_processing(int len, float* out) is
> called, it returns 0.  GR_LOG_DEBUG(d_logger, boost::format("Detected
> event on sample %l%", i)) should be executed. But I couldn't see the output
> in my screen. I was thinking I might have missed some setup in order to use
> this  GR_LOG_DEBUG feature.
>
> Thank you.
>
> On Wed, May 30, 2018 at 3:49 AM, Müller, Marcus (CEL) 
> wrote:
>
>> Hi Linda,
>>
>> for debugging *programmatic* things (i.e. crashes, program doesn't
>> calculate what I think it should), you'd use a debugger:
>>
>> https://wiki.gnuradio.org/index.php/TutorialsDebugging
>> https://wiki.gnuradio.org/index.php/TutorialsGDB
>>
>> for debugging *algorithmic* things (i.e. I don't know why my receiver
>> doesn't get the bits that I sent), well: That's mostly wireless comms
>> engineering, and you would apply your domain-specific knowledge to
>> that.
>>
>> Both aspects of debugging take experience, but you usually get better
>> pretty quickly once you get started. Of course, especially the second
>> one, is something that an education in communications technology does
>> help a lot with – I don't know what you "are" by trade, but throw in
>> whatever you've learned: It's often that we need to transform problems
>> to forms of problems that we've learned to solve. :)
>>
>> The universal approach that works best for me is this:
>>
>> 1. Get pen, paper and a coffee (or whatever drink floats your boat)
>>
>> 2. Make a very rough block diagram of what you're implementing
>>
>> 3. Verify that this block diagram matches what you've actually built by
>> making sure every step in your system does what you think it does, at
>> least according to documentation or source code (this is an important
>> step)
>>
>> 4. (MOST important step) Explicitly write down:
>>  a) What should be happening
>>  b) What is happening instead
>>  c) A list of suspicions you already have to later work through, cross
>> out and amend
>>
>> 5. Build a simplified system that reproduces b). In GNU Radio, that
>> typically means taking the signal that leads to the problem, and write
>> it to a file sink, to be able to replay *exactly the same thing* later
>> on and work on things until the issue is fixed.
>>
>> 6. Find the *simplest possible* test input that would allow you to test
>> whether the first element in your (simplified) system works. Implement
>> that test by repeating step 4 on it: think about what it should be
>> putting out, and check that it does.
>> This can take the form of a unit test, or simply of hooking up a Qt
>> time sink to the output of that first block, or as writing things to a
>> file and opening that file with python and doing some statistics on it
>> or … . Writing a unit test of course is the coolest way: that way, you
>> can later (even automatically) check that you have no functional
>> regressions, and you document for yourself/superiors/clients that
>> you've dealt with that class of problems.
>>
>> 7. If first element does what it should, move on to the output of the
>> second, repeat step 6
>>
>> 8. If you're stuck, try rubber-ducking the problem: explain the problem
>> to someone not familiar with the overall problem (for example, a rubber
>> ducky). This is an excellent method for two reasons:
>>
>>  * You get to describe what you're doing, what you're expecting and
>>what isn't happening in a way that forces you to explain it to
>>someone who doesn't have the same knowledge of the problem as you –
>>thereby forcing you to change your perspective on the problem, which
>>very often leads to new (successful) approaches
>>  * For that explanation to not be totally insufficient¹ nor take
>>hours², you train recognizing all the factors someone else (and
>>you!!) would need to understand the 

Re: [Discuss-gnuradio] Variable in Delay block

[Yeo Jin Kuang Alvin (IA)]

Hi Ron,

Thank you! Managed to get it working. By any chance, you know how to change the 
"delay" using python over time? I tried to use QT Entry GUI shown in the guided 
tutorial, instead of if else function I tried doing for loop

def set_delay_amt(self, delay_amt):
c = 0
for a in range(0,5000):
for b in range(0,6000):
if b == 5999:
c = c + 1
t = c*0.001
delay_amt = 
int(0.04*((3500*(t-2.5))**2 + 227322562.9)**(1/2.0)
self.delay_amt = delay_amt
Qt.QMetaObject.invokeMethod(self._delay_amt_line_edit, 
"setText", Qt.Q_ARG("QString", str(self.delay_amt)))
Self.blocks_delay_0.set_dly(self.delay_amt)

I've tested the code for the one listed below and tested it out using python 
shell, got the values I want.
c = 0
for a in range(0,5000):
for b in range(0,6000):
if b == 5999:
c = c + 1
t = c*0.001
delay_amt = 
int(0.04*((3500*(t-2.5))**2 + 227322562.9)**(1/2.0)

Just that I not sure where to place it in the generated file. Thank you!




From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of Ron 
Economos
Sent: Thursday, 31 May 2018 11:16 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Variable in Delay block


You should also change the Trigger Mode in the QT Time sink to Normal.

Ron
On 05/30/2018 08:05 PM, Ron Economos wrote:

It's just a scaling issue. One sample of delay at 32 ksps is much longer in 
time than one sample of delay at 10 Msps. Try the following changes.

1) Change the number of points in the QT GUI Time sink to 32768.

2) In the QT GUI range block, change the Stop value to 1 and the Step value 
to 100.

Ron
On 05/30/2018 07:39 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Ron,

Thanks! It works for me too, but when I increase the samp_rate to 10e6, can't 
see the delay.


From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of Ron 
Economos
Sent: Monday, 28 May 2018 6:08 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Variable in Delay block


It works here. Here's a small flow graph that I tested the delay block 
operation with.

http://www.w6rz.net/delay.grc

Ron
On 05/28/2018 02:33 AM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Ron,

That means the Delay block is able to change as well, but why do I not see the 
delay when simulating on the time sink?

Thanks in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of Ron 
Economos
Sent: Monday, 28 May 2018 5:26 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Variable in Delay block


If a block variable can be changed during run time, it will be underlined in 
the properties dialog. For example, in the Multiply Const block, the variable 
"Constant" can be changed.
[block]

Ron
On 05/28/2018 01:46 AM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Is it possible for me to create a QT GUI Range and put the ID in the Delay of 
the delay block? I tried and the graph doesn't change.





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

Re: [Discuss-gnuradio] Variable in Delay block

[Ron Economos]

You should also change the Trigger Mode in the QT Time sink to Normal.

Ron

On 05/30/2018 08:05 PM, Ron Economos wrote:


It's just a scaling issue. One sample of delay at 32 ksps is much 
longer in time than one sample of delay at 10 Msps. Try the following 
changes.


1) Change the number of points in the QT GUI Time sink to 32768.

2) In the QT GUI range block, change the Stop value to 1 and the 
Step value to 100.


Ron

On 05/30/2018 07:39 PM, Yeo Jin Kuang Alvin (IA) wrote:


Hi Ron,

Thanks! It works for me too, but when I increase the samp_rate to 
10e6, can’t see the delay.


*From:*Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On 
Behalf Of *Ron Economos

*Sent:* Monday, 28 May 2018 6:08 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Variable in Delay block

It works here. Here's a small flow graph that I tested the delay 
block operation with.


http://www.w6rz.net/delay.grc

Ron

On 05/28/2018 02:33 AM, Yeo Jin Kuang Alvin (IA) wrote:

Hi Ron,

That means the Delay block is able to change as well, but why do
I not see the delay when simulating on the time sink?

Thanks in advanced!

*From:*Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On
Behalf Of *Ron Economos
*Sent:* Monday, 28 May 2018 5:26 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: [Discuss-gnuradio] Variable in Delay block

If a block variable can be changed during run time, it will be
underlined in the properties dialog. For example, in the Multiply
Const block, the variable "Constant" can be changed.

block

Ron

On 05/28/2018 01:46 AM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

Is it possible for me to create a QT GUI Range and put the ID
in the Delay of the delay block? I tried and the graph
doesn’t change.



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

Re: [Discuss-gnuradio] Variable in Delay block

[Ron Economos]

It's just a scaling issue. One sample of delay at 32 ksps is much longer 
in time than one sample of delay at 10 Msps. Try the following changes.


1) Change the number of points in the QT GUI Time sink to 32768.

2) In the QT GUI range block, change the Stop value to 1 and the 
Step value to 100.


Ron

On 05/30/2018 07:39 PM, Yeo Jin Kuang Alvin (IA) wrote:


Hi Ron,

Thanks! It works for me too, but when I increase the samp_rate to 
10e6, can’t see the delay.


*From:*Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On 
Behalf Of *Ron Economos

*Sent:* Monday, 28 May 2018 6:08 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Variable in Delay block

It works here. Here's a small flow graph that I tested the delay block 
operation with.


http://www.w6rz.net/delay.grc

Ron

On 05/28/2018 02:33 AM, Yeo Jin Kuang Alvin (IA) wrote:

Hi Ron,

That means the Delay block is able to change as well, but why do I
not see the delay when simulating on the time sink?

Thanks in advanced!

*From:*Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On
Behalf Of *Ron Economos
*Sent:* Monday, 28 May 2018 5:26 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: [Discuss-gnuradio] Variable in Delay block

If a block variable can be changed during run time, it will be
underlined in the properties dialog. For example, in the Multiply
Const block, the variable "Constant" can be changed.

block

Ron

On 05/28/2018 01:46 AM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

Is it possible for me to create a QT GUI Range and put the ID
in the Delay of the delay block? I tried and the graph doesn’t
change.



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

Re: [Discuss-gnuradio] Variable in Delay block

[Yeo Jin Kuang Alvin (IA)]

Hi Ron,

Thanks! It works for me too, but when I increase the samp_rate to 10e6, can't 
see the delay.


From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of Ron 
Economos
Sent: Monday, 28 May 2018 6:08 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Variable in Delay block


It works here. Here's a small flow graph that I tested the delay block 
operation with.

http://www.w6rz.net/delay.grc

Ron
On 05/28/2018 02:33 AM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Ron,

That means the Delay block is able to change as well, but why do I not see the 
delay when simulating on the time sink?

Thanks in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of Ron 
Economos
Sent: Monday, 28 May 2018 5:26 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Variable in Delay block


If a block variable can be changed during run time, it will be underlined in 
the properties dialog. For example, in the Multiply Const block, the variable 
"Constant" can be changed.
[block]

Ron
On 05/28/2018 01:46 AM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Is it possible for me to create a QT GUI Range and put the ID in the Delay of 
the delay block? I tried and the graph doesn't change.




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

Re: [Discuss-gnuradio] random number coding problem

[Markus Wirsing]

Hi,

Does this GRC hierarchical block solve your problem?

Markus

Am 30.05.2018 um 15:31 schrieb 김무연:
> Hi all
> I was trying to make a block 
> which acts if input is 1,then output is random number and if input is 0,
> then output is the same previous time
> So last time I asked what should I use instead of rand()
> I tried to program as you told
> But I think there is something I didn't understand
> I post a picture of my screen
> So could you give me some advices?
> Thanks
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

Hi Carlo!

On Wed, 2018-05-30 at 23:04 +1000, Carlo Manfredini wrote:
> My hardware arrangement is fairly demanding, I think ?
> I wish to resample between a Red Pitaya connected via ethernet running at 
> 100kSps and a USB-audio unit (UCA-202) running at 48kSps.

That's not "much signal to process"! In the context of SDR, we're often
considering dozens of Megasamples per seconds.

> This code is simply a "loopback test" for both units running at once.

Ha, I think that's the point here.
So, this sounds like the good ole' two-clock-problem: The rate of your
sound card is slightly different from 48 kHz, and the rate of your
Pitaya. But you do a perfect adaptation between 100 and 48 kHz. So, at
the end, one device has too many or the other too little samples per
second.

> I would then add some signal processing to the signals in and out once I have 
> these working correctly.
> You can also see the break in the audio signal display in the time sink...as 
> well as the aUaUaU...
> When I view the PCs system monitor, it is using about 50% resources.

> Perhaps the USB-based audio device is struggling to operate continuously 
> given that the RP is communicating via ethernet at about 1000kBps (according 
> to System Monitor).

That's not really that much data, and you properly decimate that to the
rate your sound card can nominally do!

> USB devices tend to be "bursty" and rarely operate continuously without 
> breaks when the PC has other tasks to attend to.

Yeah, and something along these lines occasionally happens, because
talking to drivers is hard and GNU Radio's audio sink doesn't do that
in the best possible way, but really, the USB granularity doesn't lead
to discontinuities anywhere else, so why should it here?

> A screenshot of the code is: 
> https://drive.google.com/open?id=1XTNlHB87kNrX82cItMPWMvLGCGXvyr0U
> Thanks for any further suggestions.
> Maybe an option is to run the USB device at a slower sample rate ?

Really, the amount of data isn't much here. You can use your system
monitor to see how much your CPU is utilized. It should be... limited.


Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] random number coding problem

[CEL]

Hi!

So, I'm really not sure how to help you here: I have to expect you to
be able to call a function in C++ to give you value. The level of
understanding necessary to transfer my example to replace your usage of
rand() in your code isn't really high. 
Maybe you'd want to read a good C++ introductory book first[1]? That
will greatly accelerate your success!

Best regards,
Marcus

PS: having a screenshot of source code is always less comfortable to
the reader than just having the source code as text; just use copy and
paste.

[1] https://stackoverflow.com/questions/388242/the-definitive-c-book-gu
ide-and-list

On Wed, 2018-05-30 at 22:31 +0900, 김무연 wrote:
> Hi all
> I was trying to make a block 
> which acts if input is 1,then output is random number and if input is 0, then 
> output is the same previous time
> So last time I asked what should I use instead of rand()
> I tried to program as you told
> But I think there is something I didn't understand
> I post a picture of my screen
> So could you give me some advices?
> Thanks
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] debugging for gnuradio DSP programming

[Linda20071]

Thanks for your detailed information.

I have done a lot of DSP programming in other environments but not in
gnuradio. So your wiki page is helpful. The reason I posted the question is
that, I was unable to get the log output in my screen with the following
codes in the work function:

{{{

  // Do <+signal processing+>
  for (int i = 0; i < noutput_items; i++) {
out[i] = in[i] * in[i];
   int ret = do_some_signal_processing(d_len, [i]);
if (ret == 0) {
  GR_LOG_DEBUG(d_logger, boost::format("Detected event on sample
%l%", i));
}
  }

  // Tell runtime system how many output items we produced.
  return noutput_items;
}

int
detector0_impl::do_some_signal_processing(int len, float* out)
{
return 0;
}

}}}

Since every time  do_some_signal_processing(int len, float* out) is called,
it returns 0.  GR_LOG_DEBUG(d_logger, boost::format("Detected event on
sample %l%", i)) should be executed. But I couldn't see the output in my
screen. I was thinking I might have missed some setup in order to use
this  GR_LOG_DEBUG
feature.

Thank you.

On Wed, May 30, 2018 at 3:49 AM, Müller, Marcus (CEL) 
wrote:

> Hi Linda,
>
> for debugging *programmatic* things (i.e. crashes, program doesn't
> calculate what I think it should), you'd use a debugger:
>
> https://wiki.gnuradio.org/index.php/TutorialsDebugging
> https://wiki.gnuradio.org/index.php/TutorialsGDB
>
> for debugging *algorithmic* things (i.e. I don't know why my receiver
> doesn't get the bits that I sent), well: That's mostly wireless comms
> engineering, and you would apply your domain-specific knowledge to
> that.
>
> Both aspects of debugging take experience, but you usually get better
> pretty quickly once you get started. Of course, especially the second
> one, is something that an education in communications technology does
> help a lot with – I don't know what you "are" by trade, but throw in
> whatever you've learned: It's often that we need to transform problems
> to forms of problems that we've learned to solve. :)
>
> The universal approach that works best for me is this:
>
> 1. Get pen, paper and a coffee (or whatever drink floats your boat)
>
> 2. Make a very rough block diagram of what you're implementing
>
> 3. Verify that this block diagram matches what you've actually built by
> making sure every step in your system does what you think it does, at
> least according to documentation or source code (this is an important
> step)
>
> 4. (MOST important step) Explicitly write down:
>  a) What should be happening
>  b) What is happening instead
>  c) A list of suspicions you already have to later work through, cross
> out and amend
>
> 5. Build a simplified system that reproduces b). In GNU Radio, that
> typically means taking the signal that leads to the problem, and write
> it to a file sink, to be able to replay *exactly the same thing* later
> on and work on things until the issue is fixed.
>
> 6. Find the *simplest possible* test input that would allow you to test
> whether the first element in your (simplified) system works. Implement
> that test by repeating step 4 on it: think about what it should be
> putting out, and check that it does.
> This can take the form of a unit test, or simply of hooking up a Qt
> time sink to the output of that first block, or as writing things to a
> file and opening that file with python and doing some statistics on it
> or … . Writing a unit test of course is the coolest way: that way, you
> can later (even automatically) check that you have no functional
> regressions, and you document for yourself/superiors/clients that
> you've dealt with that class of problems.
>
> 7. If first element does what it should, move on to the output of the
> second, repeat step 6
>
> 8. If you're stuck, try rubber-ducking the problem: explain the problem
> to someone not familiar with the overall problem (for example, a rubber
> ducky). This is an excellent method for two reasons:
>
>  * You get to describe what you're doing, what you're expecting and
>what isn't happening in a way that forces you to explain it to
>someone who doesn't have the same knowledge of the problem as you –
>thereby forcing you to change your perspective on the problem, which
>very often leads to new (successful) approaches
>  * For that explanation to not be totally insufficient¹ nor take
>hours², you train recognizing all the factors someone else (and
>you!!) would need to understand the problem, and usually these
>factors are what you need to control in order to further narrow
>down the problem. Also, in case you later discuss your problem with
>someone that you hope can actually contribute their experience,
>you've already done the narrowing down, and know what context you
>give, so that people don't have to repeatedly ask you for context to
>get the bigger picture. That's way more efficient.
>
> 9. Always, always take notes, 

[Discuss-gnuradio] random number coding problem

[김무연]

Hi allI was trying to make a block which acts if input is 1,then output is random number and if input is 0, then output is the same previous timeSo last time I asked what should I use instead of rand()I tried to program as you toldBut I think there is something I didn't understandI post a picture of my screenSo could you give me some advices?Thanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Resampling rate method assistance

[Carlo Manfredini]

My hardware arrangement is fairly demanding, I think ?
I wish to resample between a Red Pitaya connected via ethernet running at
100kSps and a USB-audio unit (UCA-202) running at 48kSps.
This code is simply a "loopback test" for both units running at once.
I would then add some signal processing to the signals in and out once I
have these working correctly.
You can also see the break in the audio signal display in the time
sink...as well as the aUaUaU...
When I view the PCs system monitor, it is using about 50% resources.
Perhaps the USB-based audio device is struggling to operate continuously
given that the RP is communicating via ethernet at about 1000kBps
(according to System Monitor).
USB devices tend to be "bursty" and rarely operate continuously without
breaks when the PC has other tasks to attend to.
A screenshot of the code is:
https://drive.google.com/open?id=1XTNlHB87kNrX82cItMPWMvLGCGXvyr0U
Thanks for any further suggestions.
Maybe an option is to run the USB device at a slower sample rate ?




On 30 May 2018 at 17:51, Müller, Marcus (CEL)  wrote:

> I'd assume this might not be a computational issue, but more of a
> hardware or hardware interfacing issue, or maybe something
> algorithmically off. Care to save a picture of your flow graph (File-
> >Screen Capture) and upload it (e.g. imgur.com)?
>
> Thanks,
> Marcus
> On Wed, 2018-05-30 at 08:25 +1000, Carlo Manfredini wrote:
> > Hi Marcus,
> > I see. I thought you were referring to the "Polyphase Arbitrary
> > Resampler"  block for a polyphase implementation.
> >
> > Having that optimisation in the "Rational Resampler" is excellent,
> > and thank you for the detailed explanation. Very helpful.
> >
> > I'll look further into why I was getting underflow issues as
> > resampling between 100kSps and 48kSps using 12/25 ratios should be no
> > problem for my i7 based PC.
> > ( I assume that what I was getting: aUaUaU...being printed onscreen
> > in GRC..and some breaks in the continuous signal)
> >
> > Regards.
> >
> > On 29 May 2018 at 23:19, Müller, Marcus (CEL) 
> > wrote:
> > > Hi Carlo,
> > >
> > > if you're using GNU Radio's rational resampler, you're already
> > > using
> > > that method!
> > >
> > > Really, at your 100 kS/s rate... things should be trivial for your
> > > CPU,
> > > even if they weren't implemented efficiently. I'm really not
> > > convinced
> > > the resampling is to blame here!
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> > > > Hi Marcus,
> > > > Thanks for that reply.
> > > > The reduction in computation with the polyphase implementation
> > > sounds very tempting esp as I'm getting underflow errors at the
> > > moment.
> > > > I will give it a try and see how it compares.
> > > > Regards.
> > > >
> > > > On 29 May 2018 at 19:34, Müller, Marcus (CEL) 
> > > wrote:
> > > > > Hi Carlo, hi Linda:
> > > > >
> > > > > as Linda said,the RR approach works really well and is
> > > numerically
> > > > > relatively stable until you hit really ugly ratios (after, of
> > > course,
> > > > > cancelling the fraction as far as possible).
> > > > > But what is "ugly" here?
> > > > >
> > > > > In theory, rational resampling by M/N (note: M,N coprime!)
> > > would work
> > > > > like the following
> > > > >
> > > > > input --> insert (M-1) zeros between each sample
> > > > >   --> low-pass 1/M-band filter to get rid of the images
> > > > >   --> low-pass 1/N-band filter to avoid aliasing in next
> > > step
> > > > >   --> throw away (N-1) of N samples --> output
> > > > >
> > > > > Now, either of the 1/M and the 1/N-band filter doesn't do
> > > anything
> > > > > useful, simply because the other is narrower.
> > > > >
> > > > > So, we reduce that to
> > > > >
> > > > > input --> insert (M-1) zeros between each sample
> > > > >   --> low-pass 1/max(M,N)-band filter against images and
> > > aliases
> > > > >   --> throw away (N-1) of N samples --> output
> > > > >
> > > > > and pay a bit of attention to the transition width of the
> > > filter (which
> > > > > will become smaller the closer the ratio M/N becomes to 1).
> > > > >
> > > > > This is all fine and dandy, but let's say max(M,N) is N=25.
> > > > > A quick calculation[1] shows that this filter might have 220
> > > taps,
> > > > > which we need to apply to 12× the input sample rate, so that's
> > > 12·220,
> > > > > that is ca 2600, multiply-accumulate operations per input
> > > sample –
> > > > > ooof.
> > > > >
> > > > > We avoid that by having an elegant polyphase implementation,
> > > which by
> > > > > the
> > > > > power of greyskull (or was it harris?) allows us to run this
> > > core
> > > > > filter
> > > > > at 1/N of the input rate (instead of M times the input rate!);
> > > so, we
> > > > > get
> > > > > 220 / 25 = 9 multiply-accumulates per input sample - which is
> > > very
> > > > > bearable, and thus, the rational resampler works very well in
> > > this
> > > > > scenario.
> > > > >

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

I'd assume this might not be a computational issue, but more of a
hardware or hardware interfacing issue, or maybe something
algorithmically off. Care to save a picture of your flow graph (File-
>Screen Capture) and upload it (e.g. imgur.com)?

Thanks,
Marcus
On Wed, 2018-05-30 at 08:25 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> I see. I thought you were referring to the "Polyphase Arbitrary
> Resampler"  block for a polyphase implementation.
> 
> Having that optimisation in the "Rational Resampler" is excellent,
> and thank you for the detailed explanation. Very helpful.
> 
> I'll look further into why I was getting underflow issues as
> resampling between 100kSps and 48kSps using 12/25 ratios should be no
> problem for my i7 based PC.
> ( I assume that what I was getting: aUaUaU...being printed onscreen
> in GRC..and some breaks in the continuous signal)
> 
> Regards.
> 
> On 29 May 2018 at 23:19, Müller, Marcus (CEL) 
> wrote:
> > Hi Carlo,
> > 
> > if you're using GNU Radio's rational resampler, you're already
> > using
> > that method!
> > 
> > Really, at your 100 kS/s rate... things should be trivial for your
> > CPU,
> > even if they weren't implemented efficiently. I'm really not
> > convinced
> > the resampling is to blame here!
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> > > Hi Marcus,
> > > Thanks for that reply.
> > > The reduction in computation with the polyphase implementation
> > sounds very tempting esp as I'm getting underflow errors at the
> > moment.
> > > I will give it a try and see how it compares.
> > > Regards.
> > > 
> > > On 29 May 2018 at 19:34, Müller, Marcus (CEL) 
> > wrote:
> > > > Hi Carlo, hi Linda:
> > > > 
> > > > as Linda said,the RR approach works really well and is
> > numerically
> > > > relatively stable until you hit really ugly ratios (after, of
> > course,
> > > > cancelling the fraction as far as possible).
> > > > But what is "ugly" here? 
> > > > 
> > > > In theory, rational resampling by M/N (note: M,N coprime!)
> > would work
> > > > like the following
> > > > 
> > > > input --> insert (M-1) zeros between each sample
> > > >   --> low-pass 1/M-band filter to get rid of the images
> > > >   --> low-pass 1/N-band filter to avoid aliasing in next
> > step
> > > >   --> throw away (N-1) of N samples --> output
> > > > 
> > > > Now, either of the 1/M and the 1/N-band filter doesn't do
> > anything
> > > > useful, simply because the other is narrower.
> > > > 
> > > > So, we reduce that to 
> > > > 
> > > > input --> insert (M-1) zeros between each sample
> > > >   --> low-pass 1/max(M,N)-band filter against images and
> > aliases
> > > >   --> throw away (N-1) of N samples --> output
> > > > 
> > > > and pay a bit of attention to the transition width of the
> > filter (which
> > > > will become smaller the closer the ratio M/N becomes to 1).
> > > > 
> > > > This is all fine and dandy, but let's say max(M,N) is N=25.
> > > > A quick calculation[1] shows that this filter might have 220
> > taps,
> > > > which we need to apply to 12× the input sample rate, so that's
> > 12·220,
> > > > that is ca 2600, multiply-accumulate operations per input
> > sample –
> > > > ooof.
> > > > 
> > > > We avoid that by having an elegant polyphase implementation,
> > which by
> > > > the
> > > > power of greyskull (or was it harris?) allows us to run this
> > core
> > > > filter
> > > > at 1/N of the input rate (instead of M times the input rate!);
> > so, we
> > > > get
> > > > 220 / 25 = 9 multiply-accumulates per input sample - which is
> > very
> > > > bearable, and thus, the rational resampler works very well in
> > this
> > > > scenario.
> > > > 
> > > > With M,N coprime, we basically get two good cases:
> > > > 
> > > > 1. N >> M (rational decimation): The core filter runs at a very
> > low
> > > > rate of 
> > > >1/N of the input rate, its length being proportional to M·N.
> > > > 2. M >> N (rational interpolation): The core filter runs at a
> > still low
> > > > 1/M
> > > >of the output rate, its length being proportional to M.
> > > > 
> > > > So, the efforts of an M/N and an N/M filter are very
> > manageable,
> > > > because
> > > > either the filter isn't that long (no M factor in the length)
> > or the
> > > > filter 
> > > > runs at a very low rate (1/N of the input).
> > > > 
> > > > A problem only occurs if M and N are relatively close to each
> > other:
> > > > 
> > > > In that case, the transition width of the core filter becomes
> > very
> > > > small, and
> > > > the inverse of transition width goes linearly into the
> > necessary length
> > > > of a 
> > > > FIR filter; at the meantime, the polyphase saving don't balance
> > that
> > > > out.
> > > > To make matters worse, a some point, having a polyphase
> > decomposed
> > > > large filter
> > > > becomes a problem for your CPU: while a modern CPU can happily
> > keep a
> > > > couple
> > > > hundred filter coefficients 

Re: [Discuss-gnuradio] debugging for gnuradio DSP programming

[CEL]

Hi Linda,

for debugging *programmatic* things (i.e. crashes, program doesn't
calculate what I think it should), you'd use a debugger:

https://wiki.gnuradio.org/index.php/TutorialsDebugging
https://wiki.gnuradio.org/index.php/TutorialsGDB

for debugging *algorithmic* things (i.e. I don't know why my receiver
doesn't get the bits that I sent), well: That's mostly wireless comms
engineering, and you would apply your domain-specific knowledge to
that.

Both aspects of debugging take experience, but you usually get better
pretty quickly once you get started. Of course, especially the second
one, is something that an education in communications technology does
help a lot with – I don't know what you "are" by trade, but throw in
whatever you've learned: It's often that we need to transform problems
to forms of problems that we've learned to solve. :)

The universal approach that works best for me is this:

1. Get pen, paper and a coffee (or whatever drink floats your boat)

2. Make a very rough block diagram of what you're implementing

3. Verify that this block diagram matches what you've actually built by
making sure every step in your system does what you think it does, at
least according to documentation or source code (this is an important
step)

4. (MOST important step) Explicitly write down:
 a) What should be happening
 b) What is happening instead
 c) A list of suspicions you already have to later work through, cross
out and amend

5. Build a simplified system that reproduces b). In GNU Radio, that
typically means taking the signal that leads to the problem, and write
it to a file sink, to be able to replay *exactly the same thing* later
on and work on things until the issue is fixed.

6. Find the *simplest possible* test input that would allow you to test
whether the first element in your (simplified) system works. Implement
that test by repeating step 4 on it: think about what it should be
putting out, and check that it does.
This can take the form of a unit test, or simply of hooking up a Qt
time sink to the output of that first block, or as writing things to a
file and opening that file with python and doing some statistics on it
or … . Writing a unit test of course is the coolest way: that way, you
can later (even automatically) check that you have no functional
regressions, and you document for yourself/superiors/clients that
you've dealt with that class of problems.

7. If first element does what it should, move on to the output of the
second, repeat step 6

8. If you're stuck, try rubber-ducking the problem: explain the problem
to someone not familiar with the overall problem (for example, a rubber
ducky). This is an excellent method for two reasons:

 * You get to describe what you're doing, what you're expecting and
   what isn't happening in a way that forces you to explain it to
   someone who doesn't have the same knowledge of the problem as you –
   thereby forcing you to change your perspective on the problem, which
   very often leads to new (successful) approaches
 * For that explanation to not be totally insufficient¹ nor take
   hours², you train recognizing all the factors someone else (and
   you!!) would need to understand the problem, and usually these
   factors are what you need to control in order to further narrow
   down the problem. Also, in case you later discuss your problem with
   someone that you hope can actually contribute their experience,
   you've already done the narrowing down, and know what context you
   give, so that people don't have to repeatedly ask you for context to
   get the bigger picture. That's way more efficient.

9. Always, always take notes, somewhere; honestly, if they're readable
to yourself, that's a bonus, but not necessary. That way, you notice
when you're about to try something overly complicated, and you notice
when you do something stupid, and it decreases the chance of you doing
something twice in a long debugging session. For structured note-
taking, I do enjoy Zim, a desktop wiki software.

Best regards,
Marcus

¹  "hey rubber
   ducky, my correlation TDOA system doesn't work" would not make the
   ducky any smarter about the problem, but a
   "hey rubber ducky, I've 
   got this TDOA receiver based on a windowed crosscorrelation of two 
   WiFi packets, but I'm getting two peaks in the crosscorrelation
   function, but I need exactly one to find the time difference!"
   might make ducky look you in the eye and tell you to look at the
   autocorrelation function of your WiFi packet.
²  "hey rubber ducky, so I've got this job where they pay me to
   implement software, and so I thought I'd try my hands at finding the
   location of RF car keys through SDR; you see, I've been fascinated
   by car keys for nearly as long as I can think. I think it all
   started when my grandpa…"
On Tue, 2018-05-29 at 20:59 -0400, Linda20071 wrote:
> Hello everybody,
> 
> Are there any good tutorials or videos on youtube that explains how
> to do