GNURadio BPSK Position Costas Loop and Clocksync

Started by RonWei 2 years ago6 replieslatest reply 2 years ago770 views

Hello folks,

I'm having a problem understanding GNU Radio and the BPSK examples right now.
In all examples in the www, a clock sync block is used first after reading in the signal, then a Costas loop.
Shouldn't it be the other way around?
The Costas loop is designed to lock the local oscillator to the carrier signal, right? Only when this has happened can I examine the bit stream and determine the symbols and the bit length there.
Why is this getting mixed up in all the examples on the web? And that should work?

As an experiment I generate a 1kHz carrier with an STM32, BPSK modulated and always sends out a "U" (...101010101010...).
Works great, I can see the phase jumps on the scope. I read the signal into GNU Radio via a sound card.
I do without framing, it is sufficient in the first step if I see alternating bits at the back in GNU Radio.
However, that doesn't work. It doesn't matter whether I take examples from the web or build them myself (see screenshot). Also the position Costas Loop/Clock Sync or Clock Sync/Costas doesn't matter.

If I don't pack the bits to the byte and just write the bits away, I get what you see in the HEX editor.
But that's not what's being broadcast! But the signal on the sound card (and GNU Radio after LPF) looks good, exactly the same as on the scope with the alternating phase jumps [....01010101010101010.....] .



Best regards

[ - ]
Reply by SlartibartfastDecember 5, 2022

The carrier phase detector used to lock the phase recovery loop uses the constellation points as the expected phase reference.   It can only do reliably that if the symbol timing is locked or reasonably close to being locked.  This becomes even more of an issue for higher-order modulations with more complex constellations.

So, yes, the symbol timing recovery generally happens first.   The symbol timing loop will lock regardless of whether the carrier phase is locked, but the carrier phase can't lock reliably without symbol timing being reasonably accurate.

And I'd suggest not making conclusions based on pathological data patterns like alternating ones and zeros.  Random data is a good general test sequence.   e.g., you can make the phase loop lock without timing with all ones or all zeros, because there is no distinction between the symbols (assuming a digital system with no DC offset removal). 

[ - ]
Reply by kazDecember 5, 2022

It makes sense to me that to get Costas loop working you need to clock it at symbol clock that was originally generated at Tx and recovered at Rx.

A carrier tracking with wrong symbol clock wouldn't work.

I know some designs use both symbol clock recovery and carrier tracking in one feedback loop.

[ - ]
Reply by RonWeiDecember 5, 2022
Thank you for the answers!
But i dont understand how clock sync can work against an off frequency signal.
Seems to me like locking to the carrier should be the first thing one does, no?
In order to be able to measure a signal and its symbols, an RF local oscillator must first be locked onto the carrier with correct frequency and phase at the receiver end. This is how it is taught in all textbooks and writings and I also find it logical.
Also in the GNU Radio Help it says: The Costas loop locks to the center frequency of a signal and downconverts it to baseband.
How is clock sync supposed to work if the signal still has a frequency and phase offset? And that's exactly why you use PLLs or Costas in the first step?!

But I claim no expertise, so I assume the GNU Radio tutorial is totally correct, even if my test transmitter does not show an alternating bit sequence here in the GNU radio receiver.

Btw: Of course I would send random data at a later date and not just.... 01010101.... but at the beginning I would like to see if this easily recognizable bit sequence is present at the output of the GNU radio receiver. You can quickly check that with your eyes! Random data, real data and also framing comes much much later. First the base has to work.
[ - ]
Reply by neiroberDecember 5, 2022

No, the timing synchronization must occur before carrier synchronization.  I know this from designing QPSK demods.  There is some limit to the amount of carrier frequency error allowed.  For example, it can't be so large as to mangle the down-converted signal in the baseband I/Q filters.  Typically, the carrier frequency error is small compared to the signal's bandwidth.

This figure shows the signal acquisition process in a QPSK receiver. The various loop voltages are held constant until the loop is enabled by software. You can see that the clock-recovery loop (red) is enabled at about t= 16 ms.  Once the clock loop has had time to settle, the carrier recovery loop (light blue) is enabled at t = 41 ms or so.

Note that the clock recovery loop functions even while the constellation is rotating, as indicated by the violet "snr" signal, which is actually "noise-to-signal" in this case.  The "noise-to-signal" only improves after carrier lock.



[ - ]
Reply by RonWeiDecember 5, 2022

Hello Neil,

"There is some limit to the amount of carrier frequency error allowed."

This helps me. I also found two videos:



The whole process is now clearer and my brain can accept this order of the blocks. Also your diagram is top! Many many thanks!

[ - ]
Reply by DougBDecember 5, 2022

Joint recovery of carrier and symbol timing (and gain and channel) is very common.  I will often use decision directed algorithms that will fail by themselves, but work great in a joint recovery algorithm - and they work better than non data aided algorithms that you would otherwise need to recover symbol timing without carrier phase.  Convergence is faster as well.  The choice of algorithm depends on the nature of the channel distortions that are expected.