SDRPlay+WSPR+Bandwidth

Discussion in 'Software Defined Radio (SDR)' started by VE7BPB, Nov 14, 2018.

ad: L-HROutlet
ad: l-rl
ad: Left-3
ad: Subscribe
ad: L-MFJ
ad: Left-2
  1. VE7BPB

    VE7BPB Ham Member QRZ Page

    I have been experimenting with reducing the audio bandwidth when using wspr on my SDRPlay RSP2. Joe Taylor, K1JT, says that you don't need to use less than a standard ssb audio bandwidth for wspr rx, that the software will work just fine over 2.8 khz even though the wspr bandwidth is only 200hz. And as far as I can tell that appears to be correct.

    I did some testing by reducing the audio bandwidth to 300hz, centered on 1500hz (center of the wspr bandwidth) and found that there was not really any noticeable change in in rx SNR.

    However, what I did find is a significant difference in DT, which is an indicator of, among other things, how long it takes your computer to decode the wspr signal.

    In my case I am using SDRConsole V3 to receive on 4 frequencies simultaneously; one is 40m wspr and the other 3 are on 40m, 30m and 20m FT-8. I am using 3000hz bandwidth for the FT-8 frequencies and was using 1000hz (1000-2000) for the wspr frequency. Typical decode time for the wspr frequency (using wspr in WSJT-X) has been 1.8 to 2.6 seconds as shown in the DT readout.

    When I switched to using 300hz wspr bandwidth the DT time went down to 1.0 to 1.3 seconds.

    (An aside, the DT for my IC-7300 is typically .1-.2 seconds using it's built in soundcard over USB)

    So, why do we care?

    Well, it seems to me that the longer decode time is caused by wspr having to try to decode the wider bandwidth while the computer is simultaneously decoding the 3 FT-8 frequencies, and by reducing the bandwidth it requires less computer horsepower to decode the wspr signals (which I suspect are more intensive to decode), which by extension makes it all more efficient. So for instance, someone using an older slower computer with an SDR would find things happening just a little bit faster. Thereby also allowing the use of more virtual receivers at the same time before running out of computer resources.

    Something to consider for those who are wspr users, and also something to keep in mind for sdr users in general that bandwidth and computer requirements are closely related.

    regards, Roy
     
    KC4RSN, W4RAV and KK4NSF like this.
  2. KK4NSF

    KK4NSF Ham Member QRZ Page

    that makes sense to me..... and could be of special importance for those of us who will be using SDRplay SDR2pro on lower powered laptops in the field.
     
  3. VA3VF

    VA3VF Ham Member QRZ Page

    I was under the impression that DT was the timing difference between your 'receiving' computer and the 'transmitting' computer. For example: a positive DT indicates that your 'receiving' computer has measured the 'transmitting' computer to start its TX cycle late. Hence the need to have an accurate PC clock at both ends. When that happens, the DT tends to zero.

    As for the faster decoding at narrow BW, it makes sense.
     
    Last edited: Nov 14, 2018
  4. VE7BPB

    VE7BPB Ham Member QRZ Page

    You are correct, and with an analog radio that would be entirely the case. But with an SDR the DT includes the time for the computer to decode the signal from the SDR, which is affected by the bandwidth being decoded.

    At least, that's how I see it, hi.

    regards, Roy
     
  5. KA8NCR

    KA8NCR Ham Member QRZ Page

    I would think most of the processing time is dealing with the 8MHz of incoming IQ data.
     
  6. VA3VF

    VA3VF Ham Member QRZ Page

    I think you are right. The RSP1A will handle up to 10MHz at a time. I don't know how much the IC-7300 will do, but if it's determined buy the built in sound chip, it's 96 kHz, is it not?
     
  7. VA3VF

    VA3VF Ham Member QRZ Page

    Try reducing the SDRPlay sampling rate to see if that makes a difference.

    If using an RSP1A, by reducing the sampling rate from 10 to 6MHz, there is a gain of 2 bits in resolution, from 12 to 14 bits.
     
  8. KA8NCR

    KA8NCR Ham Member QRZ Page

    If you are going to process wide bandwidths, it really helps to have SDR-Console use CUDA cores. You can pick up a fairly cheap NVIDIA card with enough horsepower to offload a lot of that processing on the graphics card.

    For a while, I did exactly as you are doing with respect to WSPR, and found that the performance with the RSP1 at wide bandwidths was fairly "meh" for WSPR as compared to the narrowest inputs. I eventually started monitoring each band at 20 minute increments individually with SDR# (there is a simple json interface to control it).

    If I remember correctly, Console has remote control access via Hamlib, I think it will take the use of virtual serial ports. You could set up your three receivers and flip it to the various bands at regular intervals. At 500KHz sample, it will only light up the receiver for that band.
     
  9. VE7BPB

    VE7BPB Ham Member QRZ Page

    You are probably correct, however, your observation has no pertinence to the original post, which was about DT changes in wspr due only to changes in the audio bandwidth.

    You will note I specified the exact conditions under which this occurs, specifically with multiple virtual receivers across a fairly wide bandwidth.

    I am also running a second computer with an RSP2, tuned only to 40m and FT-8 and using 500khz rf bandwidth. When I reduce the audio bandwidth from the nominal 2800hz down to 350hz, guess what. The DT goes down, implying that significant processing time within the wspr program is not spent on the rf bandwidth, but rather on the actual bandwidth used by defined virtual receivers.

    Thanks for your contribution.

    regards, Roy
     
  10. KA8NCR

    KA8NCR Ham Member QRZ Page

    Baseband sampling and processing creates a constant delta-t for all the WSJT inputs. As far as the observed behavior of audio sample bandwidth vs processing time; yeah. that is kinda how it works.

    (edit to fix quote)
     

Share This Page