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