I have designed an SDR threaded pipeline to boost performance of my software defined radio project. Take a look.
Recently, I have been writing SDR software to recording of dual channels of I/Q data from the radio. My main use case for this gear is to allow unattended recording of BCB at night, and then use playback to copy different directions with my loop array.
I discovered that, while my prototype was working, its performance was poor. It worked fine, but consumed 80% of my CPU cycles. Not good. So, I went back to square one and developed a new architecture.
Now, I have an SDR threaded pipeline which works in the background to perform DSP without heavy computer load. Here is a demonstration video of my software in action.
With a multi-core CPU, you can devote some of the CPU to the user interface, and the rest to heavy duty DSP. I am using three separate threads in my SDR threaded pipeline. The first reads data and does recording. My second thread sequentially crunches the numbers. And the final stage produces audio and data for on-screen display.
All in all, this approach reduced CPU load from 70-80% down to 2-3%. Yes, you read that right. Now my ordinary i3 PC runs software defined radio easily.
SDR Threaded Pipeline Design
I designed this for flexibility, also. Each pipeline stage uses generics. This means I can easily adapt the pipeline to different input and output objects, as shown below.
Each thread takes in a data format T1, and emits the results in format T2. These <T> generics can adapt to any data format. In addition, I write the processing code as a separate function that I can inject into the thread to do the processing. So, for example, T1 could be 24 bit single channel samples from the Perseus, or 16 bit dual channel samples from the SDRplay RSPduo.
As shown in the video, my current test bed processes 500,000 samples per second from the Perseus into audio in just 2 milliseconds, which is around 5% of the time available between arrival of blocks of data from the radio. (Sorry, this post is very geeky, but programmers will get it!)