Posts by SWL - markro92

M0VKK: i can see that you set the wrong modcode. Try QPSK 2/3 for the beacon. The wrong FEC setting also causes the high CPU load. I'll automate that in future versions, but for now it needs to be set manually.

Ok, without attenuator the FFT plot also looks fine. far from overdriving

I would have more information if you captured the whole window in your screenshot.

What exactly goes wrong? timing or carrier lock?

Do you see a circle in the FFT plot? or just noise?

If you just see a circle, you maybe need to increase carrier recovery gain a bit until it locks. When there is no circle, you don't have timing lock and you need to re-adjust the symbolrate because the PLL loop drifted away. You can see that happening when the symbolrate on the bottom of the screen drifts away from the symbolrate you've set with the slider.

M0VKK: do you have a high gain LNB? how does the FFT look like? with and without the attenuator. i almost cant believe that it's overdriving with the gain slider all to the left

@DB8TF: thanks for your feedback. Symbolrate Presets are already done and will be in the next version. Finding the Symbolrate automatically isn't actually that hard to do, i could experiment with that and it will definitely be done, but i think that are more important things right now. Definitely in the TODO list. Same thing for automatically setting modcodes. That would actually be easy to change. Just now, there is no other information passed between the Demodulator and the LDPC worker apart from the XFECFRAME symbols itself. The Modcode information is only being displayed in the console window for now. Saving settings for each input device will definitely be done in next version, as it starts to annoy me, too. I only have the RX channel configurable for the LimeSDR right now (which i should also do for the sdrplay). Because of the LNB stability, yes, "wobbling" LNBs are worst with low symbolrates. The Beacon should work fine, though.

@DJ0MY: yes, i got in touch with him and i'll receive airspy samples soon. After adding Airspy support i'll post a new version where i also fix the issue with UI skins people are having, additional config options, symbolrate presets and LO frequency input (requested by S51KQ). that will be version 2.0.11.

sync_confidence display is unreliable for DVB-S2 by the way and needs fixing as well.

The next major update will be 2.1.0, which will be a partial rewrite and cleanup of the codebase, also adding new features like multi-transponder reception for people who want to watch full duplex QSOs. Also, MER display should make it into version 2.1.0. DVB-S1 settings are quite annoying right now, because they are different from DVB-S2, so they need additional UI elements. The symbol skip button and derotate sliders will disappear in the feature, because finding the right FEC and derotate setting for DVB-S1 can also be done automatically. It's basically trial and error, because DVB-S1 has no frame structure with that information encoded in a header like DVB-S2 has. After that's done however, i should provide some documentation for this software (of course with screenshots and explanation videos as well)

As always, thanks for your feedback and suggestions.

Marcel

DB8TF: Hi, just enter the IP address of the VLC PC. in VLC you use the same URL as always, it's udp://@:8888

@SM4IVE: i dont really know that your question is. do you mean FEC modes for DVB-S1? They are 1/2, 2/3, 3/4, 5/6 and 7/8. DVB-S2 has many more.

Well, QPSK 1/2 is the standard one you can say for DVB-S1, because the native coderate for the Viterbi algorithm is 1/2 (the number of coded bits is twice as many as in the input data) and to do the other coderates, it uses puncturing.

That means that some bits are not transmitted, and on the receiving end, they are just replaced with zero symbols, which just means uncertainty whether a 0 or a 1 has been received. Because when soft-symbol decoding is done, the I and Q amplitudes are the probability that a certain bit has been received (I and Q coding one bit each).

So a symbol in the constellation plot which is very far right on the edge is more likely to be a 1 than a 0, when we look at the in-phase component of the complex symbol.

Puncturing increases the usable datarate, but is more prone to errors.

Depuncturing is done in the receiver before doing viterbi decoding. You use the normal 1/2 Viterbi algorithm on the depunctured data. that's what i got wrong in the beginning so i'll write it here, too

iw1qef: you could lower the samplerate form 8MHz to 5MHz, that should improve performance a little bit. But the main Problem is low SNR, because the LDPC Worker has more work to do. Settings seem fine.

I think you have a 80cm dish, is that correct?

I'm not very familiar with ARM CPUs. I know that the latest Raspberry uses the A53 CPU from ARM, but i don't know how it performs in comparison to a recent x86 CPU. The good thing is that there is SIMD support (ARM NEON instructions). As a majority of the computationally heavy code in my program is written in x86_64 assembly, i'd need to port it to ARM NEON code and do performance tests. Maybe i'll do that in the feature, but i dont think that it will happen soon.

I think the A53 CPU is roughly comparable with Intel Atom CPUs. Doesn't seem promising. It's a mobile CPU after all.

Hi S51KQ,

Just put that onto my TODO list, thanks for the feedback

@DG7YEO: one last tip: try to reduce your samplerate from 8MHz to 5MHz, that should reduce CPU load a bit. But LDPC decoding is clearly the bottleneck here. That only gets better with strong signals, because LDPC decoders need a few attemps (iterations) until the signal is free of errors. So more computing power is needed for weak signals.

You may have problems with the beacon, but the other Signals should be fine.

DH2VA: i can't see a problem with the settings, everything else seems to be fine. So i think that your signal is a bit too weak. Are you able to receive it with other equipment? Also try lowering the Carrier Recovery Gain setting a bit, to about 1. That should help with noisy signals, but i doubt that this is the problem

Version 2.0.10

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

Changelog:

• Added Support for SDRPlay (only tested with RSP1A, Channel A for now)
• Added 2,8MHz and 3,2MHz Bandwidths for RTLSDR. They not always work because of USB2.0 limitations, but some people have luck with that, so i've put them in.
• Made the FFT Plot detachable from the main window.

Known issues (to be done in next version):

• Demodulator is losing lock too often
• SDRPlay device cleanup code crashes the application

The next version will be a major update (2.1.0) and will enable multi-signal reception along with some GUI changes. Maybe ready in one or two weeks.

Edit: maybe i'll also re-add the equalizer (CMA)

That's performance hungry, but it should reduce reflections and non-linearities in the receive channel.

DD1US: Ich nutze den LimeSDR hier schon seit längerem ohne Probleme, du hast sicher schon versucht den LimeSDR neu anzuschließen. Hatst du mal versucht die Firmware vom LimeSDR neu zu flashen? Meine war auch veraltet. Aber trotzdem komisch wenn der nicht in der Liste auftaucht. Ist das ein LimeSDR mini oder der normale? Und hat es mit einer älteren Version schonmal funktioniert?

@IU2KAC: no timing lock. can you change the symbolrate slider slightly? That resets the timing recovery PLL. If you have timing lock, you should see that the number at the bottom of the screen (ksym/s) stays very close to the symbolrate you set with the slider. The other settings look good

@F0FYF: to your config file question: the only two options that exist are for the LimeSDR, and there are default values inside the config.ini.

Version 2.0.9 is out!

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

Changelog:

Huge performance gain for the DemodWorker (around 700% on my CPU)

This was the main bottleneck, and overall performance should be much better now for most users. I expect this release to run on much older PCs / laptops now, without overflowing the buffers.

Details:

• Finding the starting sequence of a DVB-S2 frame (SOF) is done by using a correlator that compares the incoming symbols with a fixed (previously known) sequence of symbols. The biggest performance gain was achieved by disabling it after detecting SOF, and re-enabling it inside the last payload slot.
• Replaced the PL-Scrambling sequence by a lookup table instead of calculating it on the fly.
• Optimized the code doing carrier recovery
• Threw out old debug code

Also... my SDRPlay (RSP1A) arrived today, so next Version will probably have support for it. k, that's it for now, and thanks for all your feedback!

ON7NDR: dindn't you say that you have a dual core i3 CPU?

Pentium 3 from 1999 can't be correct, that would surprise me :D:D:D

But thanks for sharing your results, glad to see it working so well

@F0FYF: Linux support is planned. I'm just mostly using windows 7, and i'm too lazy to do a port :O I'm using Qt5 as GUI Framework, which is very easy to compile on linux, the only problem is the platform specific assembler code, but changing that won't be taking a lot of time either. The libs for SDR I/O can be linked as shared library, i think every linux distribution atleast comes with librtlsdr. Using WINE is a great idea though, but i will definitely do a native linux build. When i'm testing this, it will probably be on ArchLinux.

Hi Miguel,

SDRPlay will be first, but i think i will implement the plutosdr too. Don't have one, depends on how clear the documentation / api description is.

I also think that i will allow raw sample input via UDP, to make everything more flexible. That should be useful for USRP type SDRs (or interfacing with GNURADIO)

Version 2.0.8

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

Changelog:

• Fixed bad multithreading bug where the Demod Worker thread loses lock after changing the FFT Size slider.
• Fixed UDP packets not starting with sync byte 0x47 to increase compatibility with other software (thanks to evariste (f5oeo) for reporting)
• The same as above also applies to MPEGTS file recordings.
• The RF Filter slider is now only enabled for devices that support it.

IU2KAC: here you go

http://v.1337team.tk/nb_screen.jpg

@S57NML: i hope that you read this, i forgot to answer your 32bit question.

No, 32bit CPUs are not supported, because that wouldn't make any sense. They are way too old and don't meet the requirements anyway. could you still tell me what CPU model you use?

IU2KAC: locking takes a bit longer, but otherwise it's the same as with other signals.

Set the symbolrate, check if you have timing lock, then enable carrier recovery.

Try high gain and damping values for carrier recovery for locking and reduce both, gain and damping when you have a lock and see a constellation. damping can go all the way to the left then, and gain should be low. If it's too low, you'll loose lock again.

After that you can choose LDPC settings. I recommend gain values of around 2.

@ik1hgi Tony: to your screenshot; is that really the beacon? i've never seen before that a transponder is cut off like that. there is a sharp edge, and that shouldn't be the case. It almost looks like DVB-T.