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: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Thursday, February 18, 2016 2:40 PM To: Landsman, Arik Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Polyphase Clock Sync, lost samples - grc3.7.9 On Thu, Feb 18, 2016 at 11:56 AM, Landsman, Arik <arik.lands...@tufts.edu<mailto:arik.lands...@tufts.edu>> wrote: Hello, Noticed interesting behavior for the PPCS block - sending a short qpsk msg (30bytes or so), approximately 10byte at the end of the msg get lost. in comparison, only one byte gets lost with the Recovery MM. But maybe it is lost elsewhere. adding padding (zero or otherwise) to the end of the sources file pushes the rest of the msg out. So this can be fixed in the flowgraph, but frankly the zero padding should probably be added in the PPCS block itself. Unless this is intended?.. I suppose it get complex to account for all use case, especially since the filter taps are passed in. had anyone encountered this before, and if so, was the solution just to mux in zeros to the end of the received msg? Thanks, Arik Arik Landsman Tufts University, ECE 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
