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
a rtl_tcp compatible IQ server for the RSP
a rtl_tcp compatible IQ server for the RSP
Last edited by f4fhh on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
Reason: No reason
Re: a rtl_tcp compatible IQ server for the RSP
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:
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.
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.
Last edited by ON5HB on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
Reason: No reason
Greetings,
Bas - ON5HB
Bas - ON5HB
Re: a rtl_tcp compatible IQ server for the RSP
I figured it out, the key is decimate factor.
This should be the correct settings to emulate a dongle on a slow CPU:
However, on a fast and modern CPU the settings can easily be these:
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.
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.
Last edited by ON5HB on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
Reason: No reason
Greetings,
Bas - ON5HB
Bas - ON5HB
Re: a rtl_tcp compatible IQ server for the RSP
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.
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.
Reason: No reason
Greetings,
Bas - ON5HB
Bas - ON5HB
Re: a rtl_tcp compatible IQ server for the RSP
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.
It's only intended for use with websdr.org software but may work with other software.
Reason: No reason
Greetings,
Bas - ON5HB
Bas - ON5HB
Re: a rtl_tcp compatible IQ server for the RSP
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.
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.
Reason: No reason
Greetings,
Bas - ON5HB
Bas - ON5HB
Who is online
Users browsing this forum: No registered users and 1 guest