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 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 . 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 ).
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.
There are two options for the GUI: Build an own one with pyqtgraph / QT or derivate one from the existing (maybe from ). 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.
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.
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?