|
From: | Landsman, Arik |
Subject: | Re: [Discuss-gnuradio] Polyphase Clock Sync, lost samples - grc3.7.9 |
Date: | Thu, 18 Feb 2016 20:36:17 +0000 |
Hi Tom,
Thank you for your reply, and thank you for the vast amounts of material you made available on the web over the years. Critical for anyone starting up. for rrc, I had firdes.root_raised_cosine(32, 32, 1.0, eb, int(5*sps*32)) passed to the PPCS. so 5*8*32 taps... This matches the # of taps in the constellation mod block. you said "30 bytes seems very large" - did you mean the 30byte message is too long, or the 10byte lost in the PPCS is too much? Also, is padding with zeros at the Rx end seems like the right approach? padding the message with zeros at the Tx seems a bit wasteful, this was just for debug. Arik From: address@hidden address@hidden on behalf of Tom Rondeau address@hidden
Sent: Thursday, February 18, 2016 2:40 PM To: Landsman, Arik Cc: address@hidden Subject: Re: [Discuss-gnuradio] Polyphase Clock Sync, lost samples - grc3.7.9 On Thu, Feb 18, 2016 at 11:56 AM, Landsman, Arik
<address@hidden> wrote:
This is a result of the filters inside the clock sync blocks. They have a group delay, so data stays inside the buffers until pushed out by newer incoming samples. Automating this behavior would be very, very tricky to do right and which doesn't cause
unintended consequences elsewhere.
By the way, the same problem is true for anything with a filter, including the M&M clock recovery block or a matched filter.
Also, 30 bytes seems very large which suggests you might be using an overly large filter.
Tom
|
[Prev in Thread] | Current Thread | [Next in Thread] |