a rtl_tcp compatible IQ server for the RSP
a rtl_tcp compatible IQ server for the RSP
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
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
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)
{
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
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;
}
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;
}
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
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
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
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
Re: a rtl_tcp compatible IQ server for the RSP
Managed get 4 RSP1A boxes loaded after changing the buffers a lot.
Why there is a 500 buffer is beyond me, I upped it to 8192 and it started working.
I have heard complaints from RTL users about the same, not wanting to init or being recognised.
Streaming is always 1024 blocks of data, so 500 makes no sense.
In my opinion it creates buffer/IQ-stream under-runs, as such devices stop working when the bus is getting overloaded.
Can't explain it in detail, but upping the buffers solved loading 4 boxes at the same time.
I do not have more boxes at the moment to see if it solves more problems.
Why there is a 500 buffer is beyond me, I upped it to 8192 and it started working.
I have heard complaints from RTL users about the same, not wanting to init or being recognised.
Streaming is always 1024 blocks of data, so 500 makes no sense.
In my opinion it creates buffer/IQ-stream under-runs, as such devices stop working when the bus is getting overloaded.
Can't explain it in detail, but upping the buffers solved loading 4 boxes at the same time.
I do not have more boxes at the moment to see if it solves more problems.
Reason: No reason
Re: a rtl_tcp compatible IQ server for the RSP
Added new features, when using -s and/or -f to fix the samplerate and/or freq, the server will ignore any changes from the client.
This is important for websdr.org when using an upconverter, you now simply set the freq and don't use progfreq.
This is important for websdr.org when using an upconverter, you now simply set the freq and don't use progfreq.
Reason: No reason