Re: [Discuss-gnuradio] Polyphase Clock Sync, lost samples - grc3.7.9

[Tom Rondeau]

On Thu, Feb 18, 2016 at 3:36 PM, Landsman, Arik <address@hidden> 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: 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:

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