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

On Wed, May 30, 2018 at 11:30 PM, Linda20071 <address@hidden> 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, &out[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) <address@hidden> 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, 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 debugging on gnuradio signal processing programming?
>
> Thanks in advance!
>
>
> Linda
>

> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

From:	Ernest Fardin
Subject:	Re: [Discuss-gnuradio] debugging for gnuradio DSP programming
Date:	Thu, 31 May 2018 14:49:11 +1000