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 > 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