qtcsdr icon indicating copy to clipboard operation
qtcsdr copied to clipboard

Basic operation of qtcsdr

Open lu7did opened this issue 6 years ago • 7 comments

Hello, I'm trying to setup a transceiver using a RTL-SDR dongle plus rpitx. I found that the receiver doesn´t seems to operate properly. On close look at the log it seems that the frequency is never changed from 89.5 MHz, what I believe is the relevant part of the log follows:

Using device 0: Generic RTL2832U OEM bandpass_fir_fft_cc: filter initialized, low_cut = 0, high_cut = 0.1 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:44674. Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:44678. Ncat: Connection refused. Found Rafael Micro R820T tuner Ncat: Connection refused. Tuned to 89500000 Hz. Enabled direct sampling mode, input 2

Thanks! Pedro LU7DID

lu7did avatar Nov 08 '18 23:11 lu7did

Hi,

The connection refused messages look bad.

Unfortunately, I have not tried to set this project up for a long time. Maybe something changed with RTL-SDR.

ha7ilm avatar Nov 09 '18 09:11 ha7ilm

Thank you for your answer. Looking at the current version of mainwindow.cpp it looks to me that the RTL-SDR dongle (rtl-tcp) is started using the CMD-IQSERVER string, and there the frequency seems to be fixed at 89500000. I'm failing to see anywhere else in the code where this is changed in reaction to changes on the GUI textbox containing the frequency and or the sampling mode. My understanding of the code is vastly inferior than yours, but if I'm understanding it correctly the frequency doesn´t seems to change. Does it? Thanks in advance, Pedro LU7DID

lu7did avatar Nov 11 '18 00:11 lu7did

It does: https://github.com/ha7ilm/qtcsdr/blob/master/mainwindow.cpp#L334 There was no point in putting a numeric up/down box to control the center frequency if it did not do anything.

I found that the receiver doesn´t seems to operate properly. On close look at the log it seems that the frequency is never changed from 89.5 MHz,

Can you hear any audio at all, or what does (or doesn't) happen exactly?

Maybe rtl_tcp starts up too slowly, and the control messages don't get through the ncat because it fails to connect to rtl_tcp. You could try to increase the timeout here: https://github.com/ha7ilm/qtcsdr/blob/master/mainwindow.cpp#L41

...from {0..10} to {0..50} for example.

ha7ilm avatar Nov 11 '18 08:11 ha7ilm

Hi, Thank you for the comments, I would surely pay your recommendations a try.

In the current status qtcsdr starts, the waterfall activates but it's unable to show any signal generated on the frequency, which is consistent with it tuning somewhere else.

Regards, Pedro LU7DID

lu7did avatar Nov 11 '18 18:11 lu7did

Hi, After the modification you suggested it started to work.

Any idea or suggestion on how to make it work with wsjtx or fldigi? (output should be redirected to some virtual cable for either of the two to be able to stream in the audio).

Thanks in advance, Pedro LU7DID

lu7did avatar Nov 11 '18 22:11 lu7did

Great! I'll keep this issue open and possibly integrate this change into the code.

You can use Pulseaudio as a virtual audio cable, and set it through pavucontrol. I don't recall whether those are preinstalled on the Pi.

Hint: look for Monitor of <sound device> entries.

ha7ilm avatar Nov 12 '18 09:11 ha7ilm

Hey, for some reaseon the waterfall doesn't show?

usagi87 avatar Jul 04 '19 23:07 usagi87