Posts by SWL - markro92

    Version 2.1.2



    • Added MER label (only DVB-S2 for now)
    • Added basic support for continuous frames; The whole BBFRAME is written to the network socket to allow extraction of GSE frames (Generic Stream Encapsulation) Thanks F5OEO for providing test data
    • Updated sdrplay_api.dll to the latest version (thanks to ON7MA for reporting)

    Known Bug: RSP1A starts with 8MHz, even though 10MHz were selected, resulting in wrong symbol rates

    Known bug: Crash for RSP1A devices when disconnecting and reconnecting again.

    Known Bug: inaccurate/jumping SNR/MER values for very low symbol rates

    I'll add support for the BladeRF SDR during the coming week, too, along with some bugfixes.

    Best wishes,


    Version 2.1.0



    • Added support for 16APSK and 32APSK modcodes
    • Fixed demodulator using wrong modcodes in ACM/VCM mode
    • Fixed a crash occuring while cleaning up buffers on program exit
    • Fixed wrong scaling of TCP input samples using the F32 format
    • Fixed IQPlot imaginary axis being flipped
    • Removed QCustomPlot dependency

    The main feature is obviously 16APSK and 32APSK support, which i've tested mostly on ACM/VCM data transponders on various broadcast satellites. Otherwise, i did tests with GNURadio. Locking 16APSK and especially 32APSK with small symbolrates can take some time and isn't as robust as i'd like it to be, but i'll make this version available for you for being able to test it.

    One of the next steps will be improving the demodulator, especially when it comes to carrier recovery, and detecting the start of frame header.

    For receiving 16APSK and 32APSK, the carrier recovery damping value needs to be very low after acquiring lock.

    Of Note: I had problems with receiver sentitivity using the HackRF on 32APSK signals. LimeSDR works better, and i assume it's because of the better resolution of the ADC, which is higher than the 8 bit ADC that the HackRF uses. I had to be very careful with the Baseband Gain setting. Using Hardware RF filters helps, too. I could see the constellation improve every time i increased the Gain setting, which is why i came to this conclusion.

    Also: this version might be less sensitive for QPSK / 8PSK constellations due to the method i use for demapping symbols into bits.

    I'll try to improve this in future versions, or use the old method for non-APSK constellations.


    Hi, i just want to let you know that a new release is around the corner.

    First, i want to apoligise for promising a release date i couldn't deliver.

    I simply lost the motivation working on this project, because

    i wanted to implement all the features in one go, getting stuck mid-way.

    So i'll do smaller releases. The first one will cover the missing 16APSK / 32APSK support.

    I do tests with broadcast transponders at the moment, but it still needs some fine-tuning.


    SWL-thorens : i fixed some issues with the FFT plot,could be resolved in the next version. Could i have your test file? maybe truncate it to a few seconds of data.

    I support Pilots on/off and also dummy frames.

    Edit: Okay, found a major bug looking at the code, i'm dividing the floats by 32768, instead of multiplying with 32768. should be easy to fix. now you know the workaround :D I actually didn't test the F32 stuff, but you could also use signed 16bit.

    @on7kec: I think i'll update the sdrplay library and some others in the upcoming release. Some of them are too old. But if the API didn't change too much, your suggestion helps. If they change it too much, the Demod GUI would crash, so i should keep them up do date more often anyway.

    Hi Tony,

    ^ There, as always.

    I forgot to write a post for it, because the forum didn't let me post messages a few weeks ago.

    There were only minor changes anyway.

    At the moment i'm working on a bigger release (v2.1) which i plan to release mid December.

    Right now i do changes to the demodulator, and a partial rewrite of the whole codebase.

    Main features will be:

    - Receiving multiple transponders at once

    - Scanning a frequency range for transponders and detecting settings automatically

    - Saving common transponder locations and grouping them

    - 16APSK and 32APSK support

    - Displaying the Signal to Noise Ratio

    - Increasing performance by supporting AVX for some of the worker threads.

    - Linux Release (probably Debian or ArchLinux)

    Optional Features:

    - OpenCL support, mainly for offloading LDPC decoding to the GPU.

    - Port to Raspberry PI 4

    Hallo Ulrich,

    Im Recording / Network Panel befinden sich unter dem Dialog zum Aufnehmen auch EIngabefelder für IP/Port und das Protokoll.

    Standardeinstellung ist, Port 8888, Protokoll ist TCP. Im VLC Player wäre die entsprechende URL dann tcp://

    Für das UDP Protokoll wäre das dann udp://@:8888



    Edit: Ich sehe gerade, dass Sie version 2.0.15 nutzen, da gab es glaube ich nur die UDP option. Ansonsten, Version 2.0.21 ist die aktuelle.

    DL3DCW: There is a config option to specify PlutoSDR Network devices.


    # iio_net_contexts: IP addresses of PlutoSDR devices.

    # Multiple devices can be specified as a space-

    # separated list.

    In the config.ini file the corresponding line looks like this:

    iio_net_contexts =

    edit: i haven't tested this in a while, but it should still work. I'll check.

    Hi, there are a few things, maybe there is an error calculating filter coefficients, can you change the symbolrate slightly? maybe to 29501?

    This is clearly a problem with timing recovery or earlier stages than that. Can you also try to increase the input gain? it seems very low. The FFT should atleast be yellow-ish. btw, there is no frequency offset info, but that's not the problem here. I did a lot of optimizations to reduce CPU load, i could give you a new version tomorrow. But don't expect too many new features yet.

    Works for me :)

    Tested with 'Antenne Düsseldorf' TP on Astra 3B @ 23,5°E.

    FEC 7/8

    Well the thing is, DVB-S1 is horrible to use at the moment, because it's kinda unclear.

    Version 2.0.21 will finally have blindscan, but until then:

    Set the FEC, and then click on "DVB-S1 Symbol Skip", and combine that with rotating the constellation with the Derotate slider. There is only one combination that works. SO you basically click a few times onto the skip button, if it doesn't work, rotate the constellation 90 degrees and skip symbols again until it works. In that case the sync_confidence value will go up and stay high without flickering.

    Ok, very good :) nice CPU. Maybe i should upgrade, too. Still have a good old Haswell CPU (5820K).

    In this case, i really think 30MSym/s should also be doable. Thanks for the feedback :)

    Which SDR are you using by the way?

    Edit: Intel says you have a Mobile CPU? is that true? I feel my PC is running on a potato right now :D

    Hi, for performance reasons, you could try to reduce the number of RRC taps to 32, and disable the update of CMA coefficients. That's the Update coeff. checkbox on the right. Can you show me the statistics view? Click on Debug -> Debug Worker Stats.

    Glad it seems to work. how fast do buffers fill on the bottom right of the window? which CPU model are you using?

    Looks promising :)

    You can save the output by clicking on the 'File' button in the 'Network / Network' section. It will ask you for a location and filename.

    Alternatively, streaming is right below that. UDP / TCP are supported. VLC URLs are for example for UDP: udp://@:8888 or for TCP: tcp://

    Hi, you can do that yourself in the config file. There is a setting called 'sr_max'. You can also edit the presets there.

    However, right now even 10MSym/s is ambitious. I've received tv feeds with 9600ksym/s before. It works with high SNR, otherwise demodulating and LDPC decoding takes too long. I'm partially rewriting the demodulator at the moment. There is a lot of potential when it comes to optimizations, but 30MSym/s seems out of reach for a software-only solution (I'm not saying it's impossible). By the way, thanks for your kind words :)

    M1CTK: do you have an AMD CPU and is is crashing?

    It should run on AMD CPUs, but i'm not able to test it. I'm only using instruction sets at the moment supported by both CPU families.

    Can you give ne a screenshot of your titlebar if the program starts up? otherwise Download CPU-Z and give me a screenshot of the first window, where CPU Name and Feature Flags are displayed. It should support up to SSE4.1. Of course i also want people with recent AMD chips to run this.

    Ok, sorry for not finding the issue earlier, i'll look into it. There are a few spots in the code that i could have overlooked. Is it just the FFT display? The actual reception should work if you rightclick and try to find the transponder by accident while only using the IQ plot. Not sure if you know what i mean. FFT is bugged, rest should work as is. I'm sure that i fixed the calculation of filter coefficients, so reception should be fine regardless.

    You are correct with 4295MHz. To be exact, the maximum frequency seems to be 2^32-1 (two to the power of 32), which is 4294967295Hz.

    @Iz5tep: maybe. The modulation is quite different, though.

    Actually, the roadmap is as follows:

    1. complete the demod gui, which is roughly:

    1.1 Making the demodulator more robust

    1.2 Adding 16APSK and 32APSK modcodes.

    1.3 Support for receiving multiple transponders at once

    1.4 Adding TX capability with LimeSDR Mini and PlutoSDR, so that it can also be used as a modulator.

    2. Creating a PCB Layout and implementing the Demodulator in VHDL. Will be running on a FPGA with USB and Ethernet interfaces.

    It will also have a step-up converter to power the LNB (LNBH-29), mixer is MAX2121 (need to find out if i can tune lower than 10700MHz), and some ADC from Linear Devices (something around 100MHz with 10bit resolution)

    3. Implementing more Standards, like DVB-S2x and DVB-T/T2