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?
