Re: [Discuss-gnuradio] Module development and debugging

[Martin Braun]

Gavin,

wow, looks like you went through a lot of learning! Maybe I can give you
some pointers:

On 09/19/2016 04:03 PM, Gavin Jacobs wrote:
> https://github.com/dl1ksv/gr-ax25
> 
> So, I learned about git, and cmake, and make, and tons of other linux
> stuff, tried to download and install, but no go. Turns out that the
> package is three years old, and not compatible with the current version
> of gnuradio. So, I used gr-modtool to create a new module and block with

Unfortunately, that's sometimes the case with these OOTs. I've moved it
to gr-etcetera.

> the same inputs/outputs as his afsk1200 block, and then take his code
> and put it in the new template. After a few more learning experiences, I
> have a block that will instantiate, and consume inputs, and print out
> some info via gr::log. But, it wasn't decoding, so I got the TNC-Test
> CD, extracted one "known good" transmission burst into a wav file and
> used that as a source to the afsk1200 block. The troubling thing is that
> it doesn't give consistent results; i.e. sometimes it decodes the burst
> and sometimes it doesn't. So, my questions are about debugging this block.

Are you saying that on the same file, it gives non-deterministic
results? If so, that might be a bug in the file, but could also be in
GNU Radio. There are rumours that there's a randomness bug in the
scheduler, but it's hard to reproduce.

> 1. Are there any tools/blocks/tips/tricks for showing debug information?
> I already have QT GUI Time Sink showing the audio waveform (so I know
> the 1200/2400 hz tones are there), but I would like to see my decoded
> bits on the same timescale. Is there a way to do that? Also, is there a
> way to freeze the GUI?

You trigger, or simply stop the output (middle click). There's probably
a way to overlay signals with different rates, but I can't think of one off

> 2. Once you have a new block built, the process to make a change appears
> to be:
> 
> - edit the source file
> - make
> - sudo make install
> - sudo ldconfig
> 
> Is the last step always necessary? Is there a better way? Is there an
> IDE that can be used to shorten the cycle? How about a debugger, with
> breakpoints and variables?

You only need to run ldconfig once typically, to notify the system that
there's a new library it needs to know about. If you can wrap your issue
into a unit test, you don't need to run make install, either.

You can also set environment variables to run your OOT from within the
build directory.
What I do is not install my OOTs into my system, but into a directory
somewhere in my home dir. That way, step 2 in your case simply becomes
"make -jN install" which will build and install in one step (using N cores).

You can use breakpoints/debuggers of course. Pick your favourite. If
you're starting off from a Python program, do 'gdb --args
/usr/bin/python FOO.py', for example.


> And I have two tangential questions.
> 
> 3. In an effort to get a visualization of the the outputs, I found this
> package by the same author as above:
> 
> https://github.com/dl1ksv/gr-display
> 
> and it even claims to be compatible with gnuradio 3.7. But I got stuck
> at this step:
> 
> $cmake -DCMAKE_INSTALL_PREFIX=<where gnuradio is installed> ../
> 
> I tried to findout "where gnuradio is installed" using the suggested
> command: 
> 
> gnuradio-config-info --prefix
> 
> which showed "/usr" but plugging that in didn't work. cmake complained:
> 
> "Cannot find gnuradio cmake Modules directory"
> 
> I could find /usr/share/gnuradio but none of the subdirectories were
> related to cmake nor Modules

Where did you install GNU Radio? And how?

> 4. For anyone who is still reading, is there a way to do AFSK
> demodulation without a custom block?

Are you talking about *audio* FSK? It's all signals/numbers/DSP, so you
can probably mix down your signal to zero IF and use the regular FSK blocks.

Cheers,
M