Hi Daniel, Thank you for the suggestions. I've disabled FLL band edge filter and narrowed Costas Loop bandwidth. I gave it a good amount of time to see if that really worked. It looks like the issue is resolved now.
Thanks a lot for the insight. Best, Ceren ________________________________ From: discuss-gnuradio-bounces+ceren.karakose=outlook....@gnu.org on behalf of Daniel Estévez Sent: Tuesday, February 04, 2025 22:30 To: discuss-gnuradio@gnu.org Subject: Re: QPSK looks like 8PSK: Need for Symbol Sync Performance Improvements at High Speed Hi Ceren, The situation you describe is not completely unusual. The Costas loop locks with a frequency error of symbol_rate / 8, which causes the 8PSK constellation you see, since there is an extra rotation of 1/8 cycles in each symbol (I am assuming you have the Costas Loop after Symbol Sync, but something similar could happen even if you have them in the opposite order). This lock is unstable, so the Costas loop would not lock like this in normal situations, but problems such as loop stress because of a large frequency error or an external "force" or too large of a bandwidth can cause this. In your case, since you also speak about an FLL, it might happen that the FLL and Costas are "fighting": by trying to lock, the FLL introduces a frequency drift into the Costas loop input, which the Costas loop input tries to counteract, but by the time that there is an effect on the Costas loop state, the FLL might be pulling in another way. The fact that you mention that this usually happens on a busy PC but not on an otherwise idle PC is very strange, though. Unless you are dropping samples (which might be another way in which the Costas loop can be stressed), it should not matter how many tasks the CPU is scheduling. The blocks should perform the same calculations (although there have been some weird bugs regarding different behaviour depending on the number of input items in work functions, which can change due to CPU scheduling). If you do see sample drops, that is the problem to fix first. If not, then I do not think that it makes sense to try to improve the CPU performance of the flowgraph. In theory it should make no difference. Some solutions I would suggest if the problem is not sample drops are understanding better the interplay between the FLL and Costas loop and trying to adjust their loop bandwidths more carefully. Perhaps you do not even need an FLL (this is likely the case if your frequency error is much smaller than the symbol rate, which will probably be true at 1 Mbaud symbol rate). Even if you need an FLL to run this modem in some realistic scenarios, it might be worth to disable the FLL (and give the modem a signal for which the FLL is not needed) in order to see if the FLL is indeed disturbing the Costas loop. Best, Daniel. On 04/02/2025 12:50, Ceren Karaköse wrote: > Hi all, > > I have a receiver for QPSK modulated signal. I'm using Symbol Sync and > Costas loop blocks along with AGC. Sample rate is around 4M samples/sec > and symbol rate is 1M baud. However, there are many other applications > running simultaniously on the computer where the GNU radio flow is > running. After a random period of time, the QPSK constellation changes > into a "8PSK" constellation. Here is the screenshot: > > > > During that disruption, I've taken some error signals and printed them > next to a reference "normal QPSK" constellation error signals. The > results are as follows: > > > > The left side shows "8psk" constellation status. FLL Error denotes fll > band edge block's error output in time domain, symbol_error denotes > symbol sync block's error output and costas error denotes costas loop's > error output. At the right side, you can see the reference values where > the constellation is in its QPSK state. As observed, costas error > increases significantly when the constellation is in wrong shape. Which > yielded me to decrease the costas loop bandwidth, but nothing changed > with regards to the frequency of such "wrong" constellations. Also, when > I shift the center frequency significantly, I observe the same "wrong" > constellation. Which yielded me to think about frequency tracking > performance of the system. However, I observed no problems at the > frequency of incoming signal (i.e., I do not have any sudden spikes that > might've caused this) nor an abnormal operation of FLL band edge filter, > which is responsible for frequency tracking. > > Another interesting observation is that when I use the flowgraph without > any additional programs running at the background, I never encounter > this problem. For example, this never happens at 1M baud and even 4M > baud at my own local computer, but happens frequently on other computers > where other programs are required to run. This yielded me to think about > how computational shortages in CPU might have been causing this. > However, I do not have any answers. Which specific filter, loop, etc. > might have been affected by an overly-busy CPU so that my constellation > looks like 8PSK (sometimes 16psk) instead of QPSK? What else can I do to > resolve this besides cutting down filter sizes, reducing taps etc? Do we > have an alternative symbol synchronizer which is optimized for high > speed applications? > > Thanks for your time! > Best, > Ceren
