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