Posts by pe1chl

    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)

    DB2OS:

    I understand... DualBoot usually isn't the best way to become accustomed to a system, because when you boot Linux you probably are locked out of your information like e-mail, documents, etc (this of course depends on your setup) and it always is just a temporary excursion.

    I am from a Unix background, my first experience with computers was on a PDP11/40 with Unix version 6, and it is like "the normal OS" for me. At home, I had the usual 8-bit stuff and later the 68000-based Atari ST, but I never considered spending money on a PC clone as it ran only MS-DOS which had so much trouble with multitasking and memory management (although I helped lots of people setting up systems with my packet radio software, DesqView and F6FBB BBS, all cross-developed on my Atari ST).

    When Linux came out, this was like a godsend. I built a 486 system with 16MB RAM, high-end for that time, installed it and immediately had a 32-bit multitasking system with demand paging and a graphical window system. Microsoft was very far away from that. I was amazed at what the system could do at that time, after being in development only for a year or so (and of course running many programs that already were written for Unix).

    I ran a phone BBS, a packet radio system (with Z8530 SCC card), and the usual software all on the same system and without spending whole days on managing HIMEM space and debugging nasty crashes due to memory overwriting.


    So for me, Linux is just the natural system to run on my PC and Windows is only an alternative that came later. Of course I had a lot to do with Windows at work but that did not make me want to run it at home.

    When VMware came out (first version), I was very enthusiastic and bought a license and ran some Windows versions as VM (Windows NT4, 95, 2000, XP), mainly for experiments and to run some software only available for Windows.

    However that became less practical once Windows was past XP due to its resource usage on my machine. Today I still use VMware ESXi on server machines both at work and in the amateur network AMPRnet/HAMNET. Our systems on that network are almost all Linux with only an occasional Windows machine for backward things like YAESU Wires-X.


    Of course today Windows is much more stable than when it all started, and you can do a lot of useful things with it. However, now that locally installed software becomes less important and more environments are moving to cloud services with web browsers as the user interface, Linux is becoming more popular again.

    (and of course most people have several Linux systems even when they do not know that...)

    Just a question to the experienced SDR freaks..


    https://github.com/pothosware/PothosSDR/wiki/GQRX


    Is it worth trying this under Windows or would you rather try it under Linux?

    I have only experience with gqrx under Linux and it works fine (no crashes).

    There is a dedicated site http://gqrx.dk/

    I currently use an SDRplay RSP1a for Es'hail-2 reception but the program also supports the RTL-SDR sticks.

    Of course there are also other SDR programs for Linux, e.g. CubicSDR.

    We'll have to find what is the easiest way of incorporating some form of locking.

    gqrx has a nice remote-control interface but it has only a single receiver.

    CubicSDR can run multiple receivers in the passband (so you can listen to more than one transmission at the same time) which could be nice as a starting point for locking to the beacon.

    However, at the moment I can not run it on my system due to a bug in combination with the native Nvidia OpenGL driver. First have to find how to work around that.

    DB8TF is right in that most of the programs appear to be "optimized for ease of programming" rather than for "least CPU usage". However on a machine that isn't 10 years behind current state-of-the-art you still can use it.

    (e.g. I have a Core2 Duo CPU E6850 @ 3.00GHz)

    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.

    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.

    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...

    The transponders were very strong, much stronger than those beacons.

    So it is possible that you received them well even with your antenna off-pointed.

    However I am sure that the satellite is not at 26e, I could clearly check that during the transponder tests and my receive of the beacons, the peak signal strength is at the same location and it is around 24.2e.

    Note that there is another satellite which sends a beacon at 10706 (not exactly the same frequency) at 26e so you can be confused by that too. When you view that on your SDR you will see the modulation is not the same as what everyone shows for Es'hail-2.

    They key point is that you should tune the "offset" value in gqrx, not the "hardware freq". Because the "offset" can be tuned without any transient effects, while changing the "hardware freq" will cause the PLL in the SDR device to unlock/lock which is clearly audible and would cause errors when receiving digital modes.

    And of course preferably you want to change the tuning without changing the "dial frequency" as well. The "LNB LO" frequency would serve that purpose if any changes to it would modify the offset rather than changing the hardware frequency, or affecting the dial frequency.

    Unfortunately the gqrx author has expressed that he will make no more changes to this program, but of course it is open-source so someone else could do that instead.

    That is great... is that something you added to that software or is it just a special setup of the existing software?

    I think the ultimate solution would allow to do this within a single program, where you select one carrier as a reference and then are free to tune around the passband but remain locked relative to that other carrier.

    (entirely in software, no hardware mod required to LNB or SDR)

    With 1.8 m dish of course the pointing is very important.

    The satellite is not yet at 26e, it is at 24.2e. So turn the dish west a little bit.

    Watch for 10.706 or 11.205 not all those other freqs that usually are local spurious or sigs from other satellites...

    Also the signal from the amateur transponder is really strong. On my 80cm dish with unmodified cheap Chinese LNB I get 50dB signal/noise when the transponder is driven to (near) saturation with a single carrier. You should be able to receive it on a campingdish.

    It is so strong that I can even detect it on Vertical polarization (about 6dB S/N)...

    H/V switching was not planned into my NB setup. But a step-up DC-DC converter is in the mail from China so I can do tests. (I have enough of the step-down models in stock)

    The 1,1M dish is far easier to point than I feared...Find 28E2, then move towards south until 28E2 drops out, then one more nudge towards south and there it is! Should be even easier when P4A gets to 26E

    Yes that is a much easier method than trying to point it to a calculated AZ/EL, as I wrote in another topic. Especially with an offset dish that is very difficult to do. We are lucky because we have strong DVB transmissions at and near the same location, of course it will be different for those that are in remote locations in the footprint.

    Ahh.. I thought you might have taken the plane to Qatar to spend the holidays verifying the transponder. But it seems like you are at home watching :-)

    What we see now looks very promising w.r.t. received signal strength.

    I have not seen the two beacons as described by DH5MK, just a single carrier of varying strength.

    (and the transponder AGC acting upon it when it became much stronger, not when it is just 20dB above the noise)