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

[Laur Joost]

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,

Laur

[1] https://github.com/gnuradio/gnuradio/commit/cc844fc43aa068f28122861e854b46fdb612cf0a.patch

[2] https://github.com/gnuradio/gnuradio/commit/8b5169b933cb4d9443ed3a8e242a22bb981c1267.patch
​

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.

Tom,

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

Should be a matter of 

cmake -DCMAKE_INSTALL_PREFIX=prefix -DCMAKE_BUILD_TYPE="Release" ../

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.

Thanks,

Laur

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:

Evening!

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

Laur

Laur,

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.

Tom

[1] http://gnuradio.org/doc/doxygen/page_stream_tags.html#stream_tags_propagation

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