rtl-server, dspserver and QtRadio no working together.

[satfan52]

I run Ubuntu 16.04 and compiled the Master Branch this morning without any issues. The three executable seems to run OK. The rtl-sdr server detects my RTL dongle and it detects the connection of the dspserver. Howver the rtlsdr-server keeps "calling back a sample" and does not seems to transmit anything is fact. The dspserver keeps indicating it is missing IQ frames all the time whichI think confirms that it does not receive anything from the rtlsdr-server. Moreover the dspserver refuses connection attempts from QtRadio, but maybe this is normal as it has nothing to "serve". Please note QtRadio works fine when connecting to the remote servers provided in the server list. I run the usual commands "rtlsdr-server -d3" "dspserver --lo 0" "QtRadio" in 3 different consoles under root privileges.

I do not see what I am doing wrong.

In other sdr receivers I have tried - there was a parameter that I do not find here and that I was expected to find in a "rtldsr-server.conf" file, but it seems such file does not exist. There the usual

"rtl=0" for frequencies above 30 Mhz "rtl=0,direct_samp=2" for frequencies above 30 mhz (direct sampling bypasses the Tuner)

Any help would be much appreciated

Regards Peter

Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Device [Generic RTL2832U OEM] successfully opened. 0x6c4240 Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Tuned to 145000000 Hz. Tuner gain set in manual mode Tuner gain set to 45.00 dB. Press q to exit. Listening for TCP connections on port 11000 client socket 12 client connected: 127.0.0.1:12000 client_thread: client connected: 127.0.0.1:12000 parse_command: 'attach 0' Exact sample rate is: 250000.000414 Hz Tuned to 145000000 Hz. 0x6c4240: Tuner gain set to 45 dB. parse_command: 'start iq 13000' xxxxxxxxxxxxxxxxxxx Starting async data acquisition... CLIENT REQUESTED 13000 port !!!!!!!!! THREAD: [0x6c4240] ***>>>>>>>>>>> Samples received: 0, 0.000 kS/s [] []

user_data_callback: #samples: 16384 i: 0.000000 q: 0.000000 >>>>>>>>>>> Samples received: 2031616, 248.006 kS/s [] [] user_data_callback: #samples: 16384 i: -0.003906 q: -0.003906 >>>>>>>>>>> Samples received: 2031616, 248.008 kS/s [] [] user_data_callback: #samples: 16384 i: -0.003906 q: -0.003906 ***>>>>>>>>>>> Samples received: 2031616, 248.001 kS/s [] [] user_data_callback: #samples: 16384 i: 0.003906 q: 0.003906

[AB9IL]

Hi Peter,

Did you also generate the SSL certificates before connecting? Also, do you have the ip & port set in the QtRadio receiver settings?

Here's a script that I use on my 16.04 system, for comparison:

https://github.com/brightflash64/Skywave-Linux/blob/master/files/scripts/rtlsdr-controller.sh

QtRadio works okay with rtl dongles, but better buffering and direct sampling would make it great. I've been working on that myself, but am mostly breaking the server haha.

Phil AB9IL

[alexlee188]

Hi, Phil AB9IL:

I suspect your buffer len change caused problems with glSDR reading from rtlsdr servers.

Please revert to the previous size ie, 16384 and see whether the problem is resolved.

Once this issue is confirmed, I can see how I can update glSDR to cater to this larger buffer.

Alex

On Tue, Jul 11, 2017 at 5:44 AM, Philip Colllier notifications@github.com wrote:

Hi Peter,

Did you also generate the SSL certificates before connecting? Also, do you have the ip & port set in the QtRadio receiver settings?

Here's a script that I use on my 16.04 system, for comparison:

https://github.com/brightflash64/Skywave-Linux/blob/master/files/scripts/ rtlsdr-controller.sh

QtRadio works okay with rtl dongles, but better buffering and direct sampling would make it great. I've been working on that myself, but am mostly breaking the server haha.

Phil AB9IL

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexlee188/ghpsdr3-alex/issues/50#issuecomment-314258693, or mute the thread https://github.com/notifications/unsubscribe-auth/AAin9RZZI-ISSfuk7_QSfbk7hYmYUNelks5sMptagaJpZM4OSDN1 .

[alexlee188]

@@ -164,7 +164,7 @@ void helper_thread (void arg) // int r = rtlsdr_wait_async(pRec->cfg.rtl, user_data_callback, pRec); int r = rtlsdr_read_async(pRec->cfg.rtl, user_data_callback, pRec, 1, // buf_num,

• 16384 // uint32_t buf_len
• 32768 // uint32_t buf_len ); if ( r < 0) { printf(" !!!!!!!!! wait async input error: [%d]\n", r );

On Mon, Aug 14, 2017 at 9:41 PM, Alex Lee alexlee188@gmail.com wrote:

Hi, Phil AB9IL:

I suspect your buffer len change caused problems with glSDR reading from rtlsdr servers.

Please revert to the previous size ie, 16384 and see whether the problem is resolved.

Once this issue is confirmed, I can see how I can update glSDR to cater to this larger buffer.

Alex

On Tue, Jul 11, 2017 at 5:44 AM, Philip Colllier <notifications@github.com

wrote:

Hi Peter,

Did you also generate the SSL certificates before connecting? Also, do you have the ip & port set in the QtRadio receiver settings?

Here's a script that I use on my 16.04 system, for comparison:

https://github.com/brightflash64/Skywave-Linux/blob/master/ files/scripts/rtlsdr-controller.sh

QtRadio works okay with rtl dongles, but better buffering and direct sampling would make it great. I've been working on that myself, but am mostly breaking the server haha.

Phil AB9IL

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexlee188/ghpsdr3-alex/issues/50#issuecomment-314258693, or mute the thread https://github.com/notifications/unsubscribe-auth/AAin9RZZI-ISSfuk7_QSfbk7hYmYUNelks5sMptagaJpZM4OSDN1 .