Posts by SWL - markro92

Hi, this has nothing to do with yor CPU, i'm having the same problem. The PlutoSDR uses libiio, which is a piece of software by Analog Devices handling all the USB stuff. but the problem is, that i need to poll the data, which means, that i need to ask it for a new chunk of samples. If i don't manage to do it frequently enough, there are lost samples. And that's the worst thing that can happen for a DVB-S demodulator...

There are many reasons for this problem. It can be the operating system not scheduling the thread often enough which does the polling. That's the case on high CPU load, or if there are peaks in CPU usage. Of course, this is an important problem, which i need to find a solution for. A temporary solution could be using lower samplerates. That improves things a little, but it doesn't fix the problem. I recommend other SDRs at the moment until i come up with a solution. As far as i know, the PlutoSDR and LimeSDR have this problem. I'll keep you posted on this.

hi tony, you have those braces [ ] below the [Generic] line. it won't work that way. change the ui_iqplot line. If oyu want to comment out a line, use the # character at the beginning.

As an alternative, you can swap the [...] lines. But Generic needs to be the one just above the options.

DJ0MY: yes, i was using 8bit input, and 16-bit filter coefficients, but the output of that has been truncated to 8bit again. But don't expect too much from it for QPSK this doesn't matter that much.

@DB8TF: that's true. You could also use the console output, which tells you how many iteration the LDPC workers need. This is independent from the CPU speed. But of course this is a very limited way of measuring performance

I'm currently updating some stuff. Just added 16-bit processing path, so that SDRs with more than 8 bits resolution are fully supported, instead of only truncating to 8-bit. I've also added Baseband AGC, instead of only using the Equalizer. The advantage of doing that, is that Timing and Carrier recovery gain values are no longer affected by input gain. I'm also planning to remove the matched filtering GUI elements, because that's the least important setting, and it can be automated easily. That's because the number of RRC Taps needed can be estimated by samplerate versus symbolrate, and the rolloff factor is coded inside the DVB-S2 header. I'll now try to fix the decision directed equalizer algorithm, and implement the missing modcodes, which are 16APSK and 32APSK. After that, i'll improve the demodulator code, and then you'll also get a linux version. Got plenty of time for coding next week.

73's,

Marcel

F8ACB: sounds fine to me Timing recovery isn't that picky, but for carrier recovery, the approach you have is correct. I'm using gain values slightly below 1 for carrier recovery gain once i acquired lock. damping all the way to the lowest setting. damping pretty much controls how fast the NCO adapts to momentarily changes in carrier frequency. If you have large frequency drifts, it couldn't keep up with a low damping value. But that's unlikely to happen anyways.

DJ0MY: i played around with that, but i never got it working properly, so i kinda gave up. if someone knows how to calculate SNR correctly can you provide me with some infos? I think it can be done with symbols only. I also only need it for PI/2 BPSK, because i can use the PLHEADER symbols for it i guess.

It doesn't matter that much. I think it's 0.2.

@Tony: Thanks for the observation, your are correct!

His signal is 2,5MHz, and the Bandwidth of the Plutosdr is set to 5MHz.

In this case, Gardner TED can barely keep up, because it needs atleast two samples per symbol to operate!

SV1BDS: You could change the Bandwidth to 6MHz and use Gardner, which i would suggest. Alternatively, stay at 5MHz Bandwidth and use M&M TED.

For people who are interested in the difference:

https://www.nutaq.com/blog/sym…ds-digital-iq-demodulator

http://www.comlab.hut.fi/opetu…CarrierTimingRecovery.pdf

SV1BDS: can you just post a screenshot of the program? Maybe i can spot the problem.

I'll check this with the newest firmware today. I haven't updated it recently.

Edit:

@SQL-SK89: also check the gain slider, maybe it's all the way to the left.

on7kec: 6MHz Bandwidth works for me, higher bandwidths never did. I recommend using 5MHz, it should work with every PlutoSDR. I left the higher Bandwidths in for testing purposes, but i never could get any Bandwidth higher than 6MHz running stable. It depends on limitations that USB hosts have. Also, the PlutoSDR library (libiio) isn't that great, because it only supports polling to get samples, which needs to occur as soon as possible to avoid dropping samples. The important word here is avoiding, i can't guarantee it, which is bad. Many other SDRs use another approach. I never had these issues with rtlsdr or the hackrf, their API is great. I'd rather use a callback based API for PlutoSDR, but i can only work with what i have, although i'm not pleased with the current state myself.

@Tony: Try uploading your video on youtube. I need to login at facebook, and even when logged in, i don't have the permission to view it. But thanks for sharing videos and screenshot, i love seeing the setup other people use.

Version 2.0.16

Download: http://v.1337team.tk/dvb-s_gui_amsat.zip

Changelog:

• Added BBGain setting to PlutoSDR devices.
• RF filter bandwidth is now changeable for PlutoSDR devices.
• Dropped samples from PlutoSDR are now less likely to occur.

Ok, this should be a lot more stable.

Looking forward to your reports

Upcoming changes will be: fixing AGC and 16-bit input path instead of truncating to 8-bit.

There will also be changes to PLHEADER syncing and hopefully 16APSK and 32APSK support.

Edit: fixed the download. Check if your version really is 2.0.16.

Marcel

Hi, i'll release a new (2.0.16) version today when i get home from work. It will fix PlutoSDR related issues only. (added BBGain and RF Filtering)

Hi, think i found out what went wrong, can someone confirm?

I released a hotfix right now (build timestamp is 00:21:58)

http://v.1337team.tk/dvb-s_gui_amsat.zip

There is another problem i noticed (atleast for PlutoSDR). Samples are being dropped when the program is resticted to only one or very few CPU cores. That's also happening when another program consumes CPU time, like watching stuff on youtube or twitch. I'm trying to find a solution for that right now.

Hi Pat. The console output shows invalid modcode (reserved) due to bad PLHEADER decoding. That's because carrier recovery hasn't locked yet. The Problem is, that for the reserved modcodes, no constellation is known. That means, that only for the first 64 symbols of each DVB-S2 frame (the PLHEADER), carrier recovery is actually active. Which means, that it can take a bit of time for the demodulator to recover from this. I noticed this earlier, but it didn't persist for a long time. However, that's because i'm currently testing with relatively stong signals, but for weaker signals, this is far more noticeable. I'll try to fix this problem. The solution should be treating these modcodes as if they were QPSK, which would be better than ignoring them at all.

ok, i'll try next week. Need to port some assembly code for that, linux x64 uses another ABI. But should be done fast. The rest is easily portable, because most SDR libs and Qt5 itself are not a problem.

btw: i also need some people with their AMD Ryzen Threadrippers testing multicore ldpc decoding

@ok8kec: nice to hear one small tip: for narrow signals like this, you can get a better constellation, if you increase the number of RRC Filter Taps. Also decrease loop damping and gain for carrier recovery after you have a lock to keep stability.

Version 2.0.15

Download: http://v.1337team.tk/dvb-s_gui_amsat.zip

Changelog:

• Fixed crash after closing and re-opening PlotoSDR devices.
• Fixed LimeSDR filter bandwidth not being changeable
• Set the minimum frequency value for LimeSDR to 10MHz to prevent freezes.
• Updated SDRPlay API to version 3.06
• Fixed wrong DVB-S1 constellation derotatate behavior
• Made local oscillator frequency changeable in config
• Made the number of CPU cores being used for LDPC decoding changeable in the config file.

I need some feedback from the SDRPlay users. You need to update your API version to 3.06 to be able to use this release.

Otherwise, these are some long requested features, like some additional configuration for changing the display of local oscillator frequency.

Thanks for testing

Marcel

Hi, sorry, but that CPU isn't supported. My Software requires SSE4.1 as a minimum. Your CPU supports SSE4a, which is a different thing. I could release a version that supports older instruction sets (maybe i will do that), but it wouldn't make a lot of sense, because many signal processing tasks benefit from SIMD instructions. Other than that, CPUs that don't support these instructions are too old anyway, in terms of general performance.

https://en.wikipedia.org/wiki/SSE4

Hi, i can try a linux build, but with less supported devices at first. rtlsdr should work for sure, already tried that one. we'll see. Will consider that for next release. But i'll need to port some of the assembler code which is a little bit of work to do.

DB8TF: That's correct, and i already thought about it. I don't have much time at the moment to work on this, but there will be an update soon with a lot of smaller fixes.