Plugins

Beginning of a plan

This is a rough idea of how I think the extension plugin could look like. The interface follows Scytale-C and the Meteor plugin interface from http://www.rtl-sdr.ru/page/komplekt-plaginov-dlja-priema-sputnikov.

The LES is selectable from the Frequency manager (otti’s idea).

The displayed frequency is the CF. Will constantly change as the demodulator will track the carrier.

The rest of the data is identical to the Scytale-C interface.

 

 

 

 

 

 

Based on the location of the Meteor plugin, this is where the Inmarsat-C extension plugin will have to go into the IQ chain:

From : http://www.rtl-sdr.ru/page/instrukcija-po-ustanovke-plaginov

Extension plugins are added to the Plugins.xml file. From the order of the plugins in this file depends the order of processing the signal in the plug-ins:

The Inmarsat-C signal has a band of 4000Hz centered at CF, 1200 bauds BPSK.
Currently Scytale-C uses internally 48000 Hz SR to decode the signal.

The current bpsk demod suffers from relying on audio input. Half the signal is thrown away to start with and then you put your trust in audio drivers for the other half. If you want to process more than one signal at a time, then you need to follow-up on another audio driver setup and the complexity doesn’t help.

So the plan would be:

  1. Tap into the SDR# IQ stream, process as needed to get a lower SR stream (I am using 48000 for audio but the signal is 1200 bauds so a lower SR would be better actually processing wise), for the signal band I need (regardless of the devices attached to the SDR#).
  2. Save for now the above IQ stream to a file; I can then put it in MATLAB and play with it make all the needed changes in the demodulator. Subsequently code it in c#.
  3. Once the demodulator works decently, still outputting hard symbols I can reconnect the rest of the existing decoder.
  4. Once the decoder works decently I can feed it directly from the IQ SDR# stream.
  5. The decoder will feed on the existing UI through UDP as it does so far; this will be okay as it is open source, if someone wants to write a tcp comms between demod and UI, great!
  6. My understanding is that the SDR# initializes the plugins based on location and library name. So it is easy to add many instances of the same plugin just by renaming the dll and giving it its own initialization string. Which will allow people to use the same plugin for multiple stream concomitantly from same baseband. So the code doesn’t even have to worry about reentrancy or multithreading. At least not from the start. The plugins can then take their frequencies from the existing SDR# frequency manager plugin to tap into the user defined frequencies for input select (Otti’s idea again).

For demod visualizations I can use the existing scatter plot I have written for scytale-c and I could use a modified FFT Zoom plugin demo code to output the signal band and then draw on it the CF as detected by the demodulator. Once these are done, I can work on soft bits and optimizing the demodulator, as it will be a lot of fun with real IQ.

From talking to SDR#: The DSP library is also accessible from within the plugins with everything you may ever need, including the decimators, DDC’s, resamplers, AGC, PLL, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *