Captures of PLL LNB drifts over time. WIth & without mods.

    In HDSDR changing of the LO freq causes a short audio dropout, because of this you can only change the receiving frequency for locking on a signal.


    A further drawback is that the signal in the upper RF window is still drifting, but on demodulating this signal it is no negative effect, only an optical issue.


    Someday a clever person will programm a SDR software that is capable of locking on a signal (in the bandwith of a RTL-SDR) and on a second (following) demodulator you can listen to SSB. That would be the nicest and easiest solution ;)


    vy73 DB8TF

    Quote from DL3DCW

    I did some short test with Gqrx remote interface: Setting LNB LO take no effects to rx frequency. Only the displayed rx frequency changes. Setting new rx frequency via remote interface works fine.

    Ok that sounds promising.

    The next challenge will be to have some process looking at the waterfall on another frequency than the tuned rx frequency and computing the frequency of a carrier.

    Do you think that is possible via the remote interface as well?

    In that case the entire thing could be built as a separate process running alongside gqrx without modifying it...

    Found the command line tool "devcal" from SvxLink package. It can determine the deviation from a reference frequency.


    Devcal and Gqrx works with two SDR sticks in parallel on my raspberry. But there is still something to do.


    Not perfekt and only for first tests. But maybe this is how a solution can look like ...



    Quote from DL3DCW

    As a quick-and-dirty solution i imagine a simple tool which directly accesses a second sdr stick, determines the deviation from the reference frequency and send the correction data via the remote interface to gqrx.

    The problem with solutions like that is that you now introduce the difference in drift between those 2 sticks as a new error... and also that it is not so practical for those who use another SDR of which it would be a bit expensive to have 2.

    I have often had the wish to run several SDR applications in parallel on the same hardware, and it should be relatively easy to do when they can use the same parameters. Just duplicate the I/Q data to both clients. But it is not very widely available.

    However, in case of using SvxLink the selections for sample rate are quite limited so you would have to set gqrx to one of those (960000 or 2400000 samples/s).

    There is a patched rtl_tcp somewhere which can do this.

    Quote from DB8TF

    pe1chl: TCXO stabilised RTL SDR sticks cost about 16€ here in DL, not so expensive.

    And after a few minutes of warming up they are very frequency stable.

    In one club machine we have 6 sticks and still not enough, mostly because applications cannot share them easily (e.g. WebSDR and SvxLink).

    A common API that can share the hardware would be very welcome...

    But of course when parameters like sample rate are different (and there are no common samplerates between WebSDR and SvxLink...) it will require a costly software resampling operation.

    In the case at hand here it might be possible to avoid this by setting 960000 samples/s in gqrx which is adequate for the NB transponder and is supported by SvxLink.

    Hello,


    Simon Brown, G4ELI writes:

    "As soon as Es’Hail 2 has been commissioned I’ll get a dish ordered and look at this issue."


    Maybe SDR Radio could be the first RTL SW that integrates the software correction ;)


    That would be great.


    vy73 DB8TF

    First "quick-and-dirty" software drift controller on raspberry with GQRX works!


    I only use a second SDR stick (0,5ppm) on the same computer and a homemade software tool. No additional hardware is required. The tool can lock to any (unmodulated) satellite signal (e.g. engineering beacon). With the SDR software can be work as usual. There a no disturbing clicks etc. in the demodulated audio.


    Now I have to do some fine tunings and tests. Also everything have to be much more user friendly. Because in the moment it is really a quick-and-dirty solution ;)


    On the screenshot below you can see the drifting signal in the main waterfall. Demodulated audio is very stable (only a few Hz deviation) over long time.



    Image 1: Software drift controller and GQRX on raspberry pi




    Image 2: "Drift free" satellite receiver ;)

    Quote from pe1chl

    Do you now use SvxLink on the second stick to listen to the correction signal?

    I only use a (modified) devcal utility from SvxLink package for calculating drift offset on second SDR stick.


    If i get GQRX working with rtl_tcp server then i only need one SDR stick for all. In the moment GQRX crashes if i want to use rtl_tcp.


    But with second SDR stick it is a nice workaround. I can live with that if i am not able to solve the problem with GQRX and rtl_tcp.

    Quote from DL3DCW

    I only use a (modified) devcal utility from SvxLink package for calculating drift offset on second SDR stick.


    If i get GQRX working with rtl_tcp server then i only need one SDR stick for all. In the moment GQRX crashes if i want to use rtl_tcp.

    You could try to use SoapySDR as an intermediate between gqrx and rtl_tcp...

    I use this layer as well for my SDRplay RSP1a which is not supported by gqrx but it is supported by SoapySDR.

    (it all sounds a bit magic)