Time synchronization for small burst of PAM-2/NRZ bits

[Lukas Haase]

Hi,

I am receiving just a few bits at a time over a radio link and I need to time 
align them due to phase mismatch. Let me briefly discuss what I mean:

https://snipboard.io/8vUgdM.jpg

This plot shows the bits I am receiving (blue) triggered on the incoming bits 
(10100110011101). The red line shows the signal after the matched filter 
(without decimation). Now it matters where the samples of the matched filter 
are taken. The worst case scenario occurs in the middle and the green line 
shows the sampled values (upsampled with zero-order-hold to show them on top):

https://snipboard.io/ufaFYS.jpg

It is evident that reconstruction is not possible. Hence I am playing with the 
"Polyphase Clock Sync" block but I do not get reliable results. In my demo, I 
set the samp_rate=400kHz and fbit=50kHz, i.e. (8 samples per symbol). The 
polyphase clock is configured according to the documentation:
  Samples/Symbol: int(samp_rate/fbit)  // 8
  Loop Bandwidth: 2*3.14/100
  Taps:           list(np.linspace(0, samp_rate/fbit/2, 
samp_rate/fbit*samp_rate/fbit/2))
                   + list(np.linspace(samp_rate/fbit/2, 0, 
samp_rate/fbit*samp_rate/fbit/2))
                  // triangular waveform of size #SamplesPerSymbol * FilterSize
  Filter size:    int(samp_rate/fbit)  // 8
  Initial phase:  int(samp_rate/fbit)/2    // 4
  Maximum Rate Deviation: 0.7
  Output SPS: 1

Since my desired pulse (rect pulse) cannot be differentiated I use the 
triangular pulse, as suggested on multiple sources on the internet. I generate 
it with numpy.linspace.

What I do in my experiments is the following: I just use an ideal matched 
filter (Decimating FIR Filter with taps set to "[ fbit/samp_rate 
]*int(samp_rate/fbit)") and trigger my plot on it. In parallel I plot the 
output of the polyphase sync plot.

In my first experiment, I put merely 10 zeros between the transmissions. This 
makes the signal de-facto a continuous bit stream. The result looks as it 
should:

https://snipboard.io/hTwXGm.jpg

It can be seen the the sampled matched filter is wrong (blue) but the output of 
the polyphase clock sync is correct (red).

Now I increase the number of zeros to hundred and suddenly the output delay 
changes randomly with respect to the constant signal. This should not happen 
for a periodic system with everything fixed (and must not happen for my setup):

https://snipboard.io/YVLgRC.jpg
https://snipboard.io/ezVQaH.jpg
etc.

If I would make a screencast, the red blocks would flicker back and forth 
similar to a signal on an oscilloscope that does not trigger properly.

If I make the numbers of zeros really large (10000), i.e., I really just 
receive a few bits, it breaks completely: Initially, the block produces some 
output which jumps around a bit as before and then it disappears completely. 
Well, if I zoom out long enough (in most cases gnuradio starts to hang) I see 
that the output still jumps around between the two transmissions, somewhere 
between, separated by 200ms:

https://snipboard.io/BAf9vL.jpg


1.) Does the Polyphase Clock Sync block work for small bursts of bits? Has 
anyone tried/succeeded before?

2.) If not, what is the second-best solution (after writing my own block)?

3.) If yes, what could I do wrong?

In my experiments, bandwidth and min. rate deviation seem to have no effect 
whatsoever. Much more surprisingly, tiny modifications on the *taps* seem to 
have a big impact which makes me uncomfortable. For example, just changing the 
taps to:

  list(np.linspace(0, samp_rate/fbit/2, samp_rate/fbit*samp_rate/fbit/2+1))
                   + list(np.linspace(samp_rate/fbit/2, 0, 
samp_rate/fbit*samp_rate/fbit/2-1))


makes a difference whether the output jumps randomly or not (just making it a 
tiny bit asymmetric).


I appreciate any experience with this blocks and I am happy to post my minimal 
demo if that helps.


Thank you!
Lukas


PS: Can I be sure that this block produces exactly "Samples/Symbol" less 
samples that input samples (with Output SPS=1)? I.e., it behaves as an ideal 
decimator?