Let the coding begin!

After last weeks talks to my mentors, we have agreed on one strategy how to detect signals out of the input spectrum. This task will be the main focus beginning with the coding period next week until the midterms. 

Signal Detection

Signal detection takes place in the Signal Detection block. All signals shall be detected with simple energy detection and threshold comparison. For this, the spectrum is estimated with an averaged periodogram or Welch’s method, which is already implemented in [1]. After that, all bins above an automatic or manual threshold are identified as part of a continuous signal. All adjacent signal bins are interpreted as one signal. The output will be a set of band edges for each signal. The signal edges will be passed as a message to a RF Map, where they are available in the whole flowgraph (derivated from [2]).

Signal Extraction

To be able to process a dynamic number of signals, I chose to use a serial data flow (since parallel is not really compatible with GRC when the actual number of paths is not known). For this purpose, a Signal Separator block will be implemented, which will generate FIR filters during runtime according to the information stored in the RF map. Then, the filtered signals will be passed serially with tagged streams. Maybe there is also a much better way to do this, but this came in my mind as first idea.

After the separation, an AMC block is placed where all detected signals are examined for their modulation technique. The examination will be done by cyclostationary features and machine learning algorithms. The results of this block will be fed back by messages to the GUI sink.

To make the detected signals accessible for the user, a Signal Extractor block will be written, where only the selected signal will extracted out of the serial stream and passed on. In this way, a user can append a custom signal chain.

Mockup of inspector flowgraph and Signal Separator block


There are two options for the GUI: Build an own one with pyqtgraph / QT or derivate one from the existing (maybe from [1]). It is not clear which one would be more sensible.

The GUI draft provides a spectrum plot, with the option to add a waterfall plot later and examine signals “from the past”. There, automatic detected signals will be marked with all information that is extracted in the signal chain (frequency, modulation). Manual signal selection will be possible, too.

Mockup of GUI (modified QT GUI sink) from proposal

Alternatives (Updated)

Another approach would be to not use a central RF map but to pass the frequency information within messages. This way, no read/write problems should occur. Also, this information is only needed in two blocks (GUI and Signal Separator), so no need for complicated message flowgraphs. By using this approach, an user can alter the frequency information that gets passed towards the Signal Separator block, which is needed for instance when selecting the signals manually.

Decentralized approach

Please feel free to give feedback on this thoughts, especially on these open questions:

  • Is it more efficient to build an own GUI or to derivate from existing?
  • How should different signals be analyzed, e.g. AMC? Is it reasonable to use a serial signal chain or is a parallel approach more suitable?
  • Is a tagged stream a good way to pass serial signals? Or would messages be more suited? Is there any solution already existing in GR for such a parallel/serial conversion?

[1] http://www.cgran.org/pages/gr-specest.html
[2] http://cgis.cs.umd.edu/~clancy/docs/sdr07-detect.pdf


One thought on “Let the coding begin!

Comments are closed.