[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] PBF clock sync tag propagation

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] PBF clock sync tag propagation
Date: Mon, 23 May 2016 10:49:29 -0400

On Sun, May 22, 2016 at 9:13 AM, Laur Joost <address@hidden> wrote:
So, results:

1. Still off, but not by that much anymore.
2. The expected location of the time_est tag is no longer in the middle, but between symbols (had to change the offset by 0.5*sps) (?)

Pretty pictures:

I can offset that remaining error by shifting the PFB filter peak around, but I doubt that this is "by design", the resulting filter is rather offset:

For my current purposes, this is enough. Questions are welcome, but I probably won't be able to do much more testing before the end of the week, if then.

PS: If it matters (something else changed that I missed), I patched my current corr_est and pfb_clock_sync blocks with [1] and [2] instead of installing the branch.

Many thanks,


Interesting and useful. I think the filter offset might be part of what you experienced as the group delay of that would be different than the filters I used for my tests. This suggests it might need a way of specifying that information. Perhaps using the declare_sample_delay concept.


2016-05-22 13:01 GMT+03:00 Laur Joost <address@hidden>:
PS: Added list to recipients. Also, I can see what was changed from the commit, duh me.


Since I already have backup of the virtual machine in place (updated GnuRadio in hopes that this was already in, I'll see if I can get this to quickly compile.

Should be a matter of 

make install

 for gr-digital only, or are there other modules that need to be changed? Or am I mistaken completely?

Will let you know whether it works for me.


2016-05-21 18:36 GMT+03:00 Tom Rondeau <address@hidden>:
On Sat, May 21, 2016 at 1:33 AM, Laur Joost <address@hidden> wrote:

I have a funny issue with PFB clock sync tag propagation.

I'm using the corr_est block to detect the start of a burst. It works fine (at least when I have a decent-enough frequency lock). However, the PFB clock sync block shifts the tags to way before the burst, causing the following Costas loop to go off lock.

The first picture shows the tags as they're supposed to be:

Second shows how they are after PFB and Costas (and yes, I checked that it's the PFB which introduces the lag).

Scanning the mailing list shows that there were issues (supposedly fixed) with tags getting lost due to rate changes. I do not have that issue, all tags come through fine.

Has anyone encountered this before and is there a workaround?

Thanks in advance


Yes, this is a known problem. The tag placement is updated based on the sample rate change of a block. For clock sync blocks like this, that rate change is not constant, even within a work function. The work-around is to stop tag propagation (TPP_DONT [1]) and then handle the tag placement within the work function.

I have corrected this behavior in my packet2 branch [2] commit [3]. We haven't moved this into the mainline tree (maint/master) because it might just be a case of 'works for me' and needs more testing.


[2] https://github.com/trondeau/gnuradio/tree/packet2
[3] 8b5169b933cb4d9443ed3a8e242a22bb981c1267

reply via email to

[Prev in Thread] Current Thread [Next in Thread]