Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts

[Garver, Paul W]

Thanks for the response. My signal actually has a pilot/clock before the preamble, which I think should help the clock sync lock, but I still wasn't getting good results. I changed the number of filters in the filter bank to 16 from 32, and this makes the clock sync work on the first packet.  From my understanding the trade space here is the interpolation is now limited to a resolution of T_s/16  compared to T_s/32. The interpolated sample may not be perfectly aligned to the true matched filter peak. My guess is the RRC filter was too long compared to the packet length.

---

From: Usman Haider <address@hidden>
Sent: Sunday, October 9, 2016 9:26:47 AM
To: Garver, Paul W
Cc: Sylvain Munaut; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts

 

Yes, you are right here. "The time_est tag can be used to adjust the sampling timing estimate of any downstream synchronization blocks and is currently implemented by the gr::digital::pfb_clock_sync_ccf block."

--

Usman

On Sat, Oct 8, 2016 at 1:13 AM, Garver, Paul W <address@hidden> wrote:

So is that what the time_est tag in corr_est_cc is for? The idea being correlate against the preamble to generate an initial timing estimate for the clock recovery to lock quickly?

PWG

> On Oct 7, 2016, at 3:37 PM, Sylvain Munaut <address@hidden> wrote:
>
>> Does anyone have insight into how to do burst timing recovery
>> with PF clock sync block? I’ll also note it appears that the M&M clock sync
>> block experiences a similar problem.
>
> Both blocks are meant for continuous signal and will take a "while" to lock.
>
> Usually for bursts, you have a sync sequence to correlate to to get an
> initial valid alignement.
>
> Cheers,
>
>    Sylvain

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio