Symbol Synchronization for GFSK/FSK signals in GNU Radio I am trying to demodulate GFSK signal, and extract the packets using GNURadio.

TX information: 

It is basically BLE transmission but customized. BW: 2MHz, data rate: 1MSymbols/sec, 1 bit per symbol. Each packet is 160 bits (which equals to 181us duration). And the packets are repeated every 100ms, hence approx. 10 packets per sec

RX information: 

I am using a BladeRF with 4Msps and storing it to a .complex and read back in GNU Radio.
The samples are given through an LPF performing decimation by 2 which reduces the sample rate to 2Msps. Then I use a quadrature demodulation block following which I use a Symbol Sync block. After this I use a custom OOT module, to count the packets. 

So, everything is perfect until the demodulation, after demodulation I can clearly see the data stream. Only thing is that we can't make a hard decision here  (we have 2 samples per symbols). In order to fix that we pass it through the Symbol Sync block. Then we do packet detection

Problem:

My main issue is not every packed is synced/recovered by this block. As most of the symbol timing recovery is a kind of estimation/control loop algorithm. Setting the correct parameters is very important. I played a lot with the parameters. And whatever I have set now works best for me.
Even in this best-case scenario, I am losing some packet. The capture file I have is for 32.03 seconds, which approx. contains 319 packets, but I can only recovery 311 packets.

I have been experimenting with this for nearly a month, with different packet rates, like 10, 25, 50, 75, 100 packets per second. All the test capture is done in a very low noise environment, and RX close to TX. So, any channel effects can be ignored. I even tried inserting a matched filter before demodulation, use a polyphase clock recovery, etc. but still, packets are lost.

And every time packet loss rate is always 5% to 7%

Questions:

1) why exactly this happens? is it because that the limit of symbol recovery can do or Am I doing something wrong?

2) is there any other alternative for this problem, to recovery 100% or at least with less than 4% loss? I have seen a technique which reverse engineer like M.ossmann's clock recovery use (https://github.com/mossmann/clock-recovery). But, I want to do it in real-time.

Any other suggestions to modify the algorithm or parameter or even approach are highly welcomed and appreciated....!!! I stuck with this problem for soo long and it's getting on my nerves.

Please, I am calling out experts in the field for help and looking for discussions.

Thanks in advance

P.S: I am attaching my screenshot of the GNU Radio flow graph. And also a plot showing how some packets are distorted after passing through the symbol sync block. The red is the bits of a packet after the symbol sync block and blue is before that. You can see that it's been lost many bits. Hence, the packet detection block is unable to detect it. 


  
  

UPDATE:

Based on the suggestion from the comments, apparently the loop bandwidth and damping factor value are not very optimal. As my preamble is 8 symbols the loop should settle to linear operation within this time. This corresponds to the loop bandwidth of ~40KHz (normalized loop BW 20m). After these changes also I was still getting a 5% packet loss. In order to analyze a bit deeper, I created a bit more detailed graph with the debug signals from the Symbol Sync block. I have superimposed the recovered packet with error, instantaneous period, average period debug signals. I am attaching the graph for both cases, where the packet is recovered/detected good and the failure case. The first image corresponds to a good packet, the second image is for a bad packet.
The Symbol Synchronizer block is a PLL-based synchronizer that is trying to estimate the symbol clock period and symbol clock phase (aka timing offset) based on the samples coming in that represent the data symbols.

Being a PLL configured with static parameters, there is a fundamental trade off between acquisition speed and tracking stability of the symbol clock estimate.  The more reactive the loop configuration, the faster it will acquire, but the more likely it may loose track later and cause an error.  The more sluggish the loop configuration, the longer it will take to acquire, but it will track much better when locked.

You can speed acquisition by using a correlator out front (e.g. the corr_est block) that detects your preamble and marks the center of a symbol with a "time_est" tag.  The symbol sync block will notice the "time_est" tag (or a "clock_est" tag) and reset it's tracking estimates right there to rapidly acquire lock.

But that is not your immediate problem.

For the symbol sync block to work well, you must understand the requirements, assumptions, and behaviors of the Timing Error Detector you have selected.

The M&amp;M TED, with the default "bpsk" decision constellation, is expecting:


symbols that are peaked in the center
symbols that ideally have peak(trough) levels of $\pm 1$
you to set an expected TED gain that comes from modeling and simulation of the TED in this particular situation (expected SNR, samples symbol in use, matched filter in use, etc.) in MatLab, Octave, Python or other M&amp;S tool of your choice.


When you model and simulate the M&amp;M TED, you may notice something peculiar about its behavior:

If you have a good estimate of the symbol clock period, then the M&amp;M TED S-curve, and hence TED gain, collapses to $0$ on sequences of alternating symbols: $..., -1, 1, -1, 1, -1, 1, ...$

This is likely why you are failing to acquire lock at the beginning of some packets when starting with some random symbol clock phase (aka timing offset) estimate.

Either use a correlator that marks a preamble symbol to jump-start the timing synchronization, or use a different TED.  The M&amp;M TED is old technology.

When using a different TED, make sure you understand its derivation and the assumptions that went in to its derivation.

Also design and modeling and simulation in MatLab, Octave, R, Python, or whatever, is absolutely essential if you want something other than suboptimal results.  GNURadio is a fine prototype tool, but is not a very good up front design tool.

Please read this brief, if you haven't already:

https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf