wow, looks like you went through a lot of learning! Maybe I can give you
On 09/19/2016 04:03 PM, Gavin Jacobs wrote:
> 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
> 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
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:
> 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
> 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.
Discuss-gnuradio mailing list