On Thu, Feb 18, 2016 at 3:36 PM, Landsman, Arik <arik.lands...@tufts.edu> wrote:
> 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. > Thanks! We've been working to provide better material for people. Glad to know it's helping! > 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. > That seems right. > 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? > I read your message too quickly. I thought you said you were missing 30 bytes. 10 bytes seems more reasonable. Basically, each arm of the filterbank will store a certain number of samples that need to get pushed out in the end. This is assumed in most applications where data is constantly streaming. But when you have a finite resource, you have to have some finishing condition to push things though. > 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 > This sounds like a simulation where you have a file starting at one point, move through the modem and store in an output file. That's fine, but if this were a live system, you'd be pulling in data constantly at the receiver, which would push samples through, anyways. So yes it's a bit wasteful in the TX here, but I'm not sure that matters too much. Tom > ------------------------------ > *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> > 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
