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) <[email protected]>
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
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
