Closed metssigadus closed 6 years ago
Hi @metssigadus,
It looks like this is not a problem with OpenWebRX. Please test your command in itself. It is outputs the I/Q samples to the standard output, then it should be working with OpenWebRX.
If you know how to interface remote SoapySDRs with OpenWebRX, then you could extend the wiki with that information.
Well, my problem has been solved now and everything is working as planned.
For a remote RTL-SDR dongle:
start_rtl_command="rx_sdr -d driver=remote,remote=tcp://10.10.1.118:55132 -s {samp_rate} -f {center_freq} -p {ppm} -g {rf_gain} -".format(rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm) format_conversion="csdr convert_u8_f"
For both instances of SdrPlay:
soapy_device_query="driver=remote,remote=tcp://10.10.1.118:55132" start_rtl_command="rx_sdr -d {device_query} -F CF32 -s {samp_rate} -f {center_freq} -p {ppm} -g {rf_gain} -".format(device_query=soapy_device_query, rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm) format_conversion=""
My utmost confusion was due to the unclear semantics of rtl_tcp and rtl_sdr . (probably one will need to further clarify their purpose in manuals & help texts):
a) rtl_tcp is a server-side utility (and won't work at the client side). One of the CLEAR explanations is available here: https://www.welle.io/devices/rtl_tcp . I should say, renaming it to e.g. rtl_srv could avoid the confusion.
b) rtl_sdr seems not to take "remote device" arguments, only [[:digit:]] to enumerate the device.
And, of course, the launching order is important on both sides to achieve the situation where each frequency band will be served by a proper SDR with somewhat correct antennas for that band. I do not see the option to use serial numbers as identificators, although SoapyRemote makes these ID's available.
Anto Veldre, ES1LAU
On 2018-06-04 13:16, András Retzler wrote:
Hi @metssigadus [1],
It looks like this is not a problem with OpenWebRX. Please test your command in itself. It is outputs the I/Q samples to the standard output, then it should be working with OpenWebRX.
If you know how to interface remote SoapySDRs with OpenWebRX, then you could extend the wiki with that information.
-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or mute the thread [3].
Links:
[1] https://github.com/metssigadus [2] https://github.com/simonyiszk/openwebrx/issues/114#issuecomment-394305134 [3]
I'm happy that it's solved. Thanks for sharing those informations.
My configuration: [1(RTL-SDR)+2(SDRPlay)] <-> [SoapyRemote installation] <-> [*x(OpenWebRX installation)].
SoapySDRUtil at the client/OpenWebRX computer is correctly enumerating the remote resources from the server:
SoapySDRUtil --find="remote=1.1.1.1"
[..]Found device 2 driver = remote label = SDRplay Dev1 RSP1A 255 1111111111 remote = tcp://1.1.1.1:55132 remote:driver = sdrplay
In case of sdr-rtl the error msg from OpenWebRX says: "No supported devices found." "NameError: global name 'clients_mutex' is not defined". In case of sdrplay the significant error msgs are: "Found 0 antenna(s):" [..] n*"WARNING: sync read failed. -5".
The problem: no clear syntax example available about how to make OpenWebRX aware of the remote resources. No idea how to markup these resources in config_webrx.py.
Extra information for possible glues: Avahi is not an option (due to routed networks). 3x(OpenWebRX) were functioning whilst resources were locally connected. The versions are the latest (git cloned a couple of hours ago). SoapyRemote on the client computer was compiled as the last item.