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
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
No comments:
Post a Comment