[Top][All Lists]

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

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

From: Laur Joost
Subject: Re: [Discuss-gnuradio] PBF clock sync tag propagation
Date: Sun, 22 May 2016 13:01:32 +0300

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]