a rtl_tcp compatible IQ server for the RSP

[f4fhh]

Hi ! Bonjour à tous !

I enjoy my RSP1A everyday but I missed the benefits of SDRSharp when it came to handling, scanning and decoding VHF signals. I also wanted to be able to connect my RSP to a remote unix server and access it over a LAN. So, I tried to port the rtl_tcp code from Osmocom and adapt it to the RSP devices. I've pretty much succeeded, at this time it run well on x64 linux with RSP1A but I need some help from friends with RSP2s, RSPduos and RaspberryPis to test the code on different devices and different OS architecture. Have a look to : https://github.com/f4fhh/rsp_tcp. The area of improvement is the 16 to 8 bits re-quantization and the gain reduction / LNAState management.

I also assembled my rsp_tcp server and some other tools in a linux docker image that works well on a x86 NAS (unraid), see : https://github.com/f4fhh/sdrplay_container. Feel free to test it and send me your comments.

Sorry about my poor English

73 de F4FHH Nicolas

[ON5HB]

I'm using your server to connect websdr.org with the RSP1A.
However, I can send larger sample rates.
I have been adding code to your "driver" and compiled it, it does respond but I doubt I have it right.

The part I added, but I doubt I have done it correctly:

Code: Select all

static int set_sample_rate(uint32_t sr)
{
        int r;
        double f;
        int deci = 1;
        if (sr >= 8000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_8_000;
        }
        else if (sr >= 7000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_7_000;
        }
        else if (sr >= 6000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_6_000;
        }
        else if (sr >= 2400000)
        {
                deci = 1;
                bwType = mir_sdr_BW_5_000;
        }
        else if (sr >= 2000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_1_536;
        }
        else if (sr >= 1800000)
        {



Please help, if you can to correct the code so I can use far more band-weight then 2048 and 2880 MSPS.
Can anybody help correcting this part?

Thanks.

[ON5HB]

I figured it out, the key is decimate factor.

This should be the correct settings to emulate a dongle on a slow CPU:

Code: Select all

        if (sr >= 8000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_8_000;
        }
        else if (sr >= 6000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_6_000;
        }
        else if (sr >= 3200000)
        {
                deci = 1;
                bwType = mir_sdr_BW_5_000;
        }
        else if (sr >= 2500000)
        {
                deci = 1;
                bwType = mir_sdr_BW_5_000;
        }



However, on a fast and modern CPU the settings can easily be these:

Code: Select all

        if (sr >= 8000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_8_000;
        }
        else if (sr >= 6000000)
        {
                deci = 1;
                bwType = mir_sdr_BW_6_000;
        }
        else if (sr >= 3200000)
        {
                deci = 2;
                bwType = mir_sdr_BW_6_000;
        }
        else if (sr >= 2500000)
        {
                deci = 2; <== or even 4!! with BW_8_000
                bwType = mir_sdr_BW_5_000;
        }



Decimate does this:

set sample rate 2880000
SR 2880000.000000, decim 1, BW 5000 Khz

And when changed this:

set sample rate 2048000
SR 4096000.000000, decim 2, BW 5000 Khz

I still wonder what the meaning of it is, but I'm an websdr.org sysop and it works in both cases, except when the CPU is an old one (meaning slow), looks to me that modern CPU's have something that old ones don't have.

Deci = 1 = translated as decimate disabled, decimate 2, 0 band filter average.
But deci = 2 is translated as decimate enabled, decimate 2, 0 band filter average.

Can anybody tell me why an Celeron847 can not enable decimate but an AMD FX6300 can.

Something is special about decimate that old CPU's can't handle it....but what? Does it do oversampling or such? As the audio-quality is better with a higher decimate number.

[ON5HB]

Has been fixed.

I forked the F4FHH source to create good drivers for websdr.org systems.

Turned out to my own problem the CPU overloaded, my kernel params used for dongles where a problem for SDRplay

The "driver" can be found here: https://github.com/ON5HB

Beware, this "driver" may not work with user software that needs a compatible RTL_TCP port.
Or it just works, I have not tested nor modified it for this purpose.

It may also work for other written websdr's like openwebrx, I do not know and it's untested.

Only thing needed the SDRplay Linux api/hw installed, no Soapy or anything.
Then clone the source from github, compile it and run it.

That's it and you are ready to run your rtl_tcp based software.

[ON5HB]

Update: I rewrote parts of the driver-server and it works great upto 2.880 MSPS and at the correct BW and decimation simply off.

It's only intended for use with websdr.org software but may work with other software.

[ON5HB]

Updated the driver to support the following sample-rates and tested against websdr.org software:

62500/128000/256000/512000/1024000/2048000/2880000

They work fine now.

As websdr.org software needs wider bandwidths it may work well for others too.