Re: errors in packet payload with n310s

[Jeff Long]

... ACK - I can't read ... ignore that last email. But the first one is still right :-)

On Tue, Aug 4, 2020 at 1:27 PM Jeff Long <willcode4@gmail.com> wrote:

"phase_est" is generated by the correlation estimator, probably being ignored by subsequent blocks, and then a tag by the same name is generated by the costas loop ... what are you seeing?

On Tue, Aug 4, 2020 at 1:24 PM Jeff Long <willcode4@gmail.com> wrote:

Is phase_est relevant (or even correct) after the PFB clock sync? If it's incorrect and being propagated to one costas loop but not the other, I'm not sure but it sounds like it could cause problems.

On Mon, Aug 3, 2020 at 11:58 AM Cameron Matson <ncmatson95@gmail.com> wrote:

Forgot to reply to the list.

---------- Forwarded message ---------
From: Cameron Matson <ncmatson95@gmail.com>
Date: Mon, Aug 3, 2020 at 10:55 AM
Subject: Re: errors in packet payload with n310s
To: Michael Carosino <m.carosino@gmail.com>

Mike,

Thanks for taking the time to look at those examples.  Your comments make a lot of sense.  I'm pretty new to this so I haven't gotten to know all the "well known" problems yet!  I will try to incorporate the differential encoding into the flowgraph.  Unfortunately, for some reason, the packet tx/rx examples don't use the Constellation Modulator/Demodulator blocks which have an option for differential encoding, so I'll have to tinker with it a bit to incorporate that, but it sounds like that will definitely help.

Interesting point about the phase_est tag only going to the header chain.  Does anyone have any reasoning behind that?

Thanks again,

Cameron

On Sun, Aug 2, 2020 at 11:40 AM Michael Carosino <m.carosino@gmail.com> wrote:

Regarding the 2nd problem you're seeing, that sounds a lot like the well known 180 degree phase ambiguity of the bpsk costas loop. I'm not super familiar with the corr_est scheme used in the packet_rx example but AFAIK if it's working correctly it should generate a tag containing an estimate of the phase using the preamble and that tag would be used by the costas as an initial condition. Assuming that the phase estimate is closer to the true phase (than one at a multiple of pi away), the costas should converge to the true phase. However - if the phase estimate is closer to one the pi-multiples (or there is no phase estimate), the costas may lock to a 180 degree multiple and result in the detected bit sequence being inverted.

I briefly looked at the packet_rx example and interestingly the header payload demux block only passes the phase_est tag to the header processing chain but not the payload processing chain. This means that the header chain's costas loop is getting an initial phase estimate while the payload chain's costas is not - in this case I'd expect the payload bits to be inverted occasionally as you're seeing. One quick check to see if this is the case would be to enable differential encoding on the payload bits to resolve the ambiguity.

I'm not sure why the payload demux block doesn't pass the phase_est tag to both the header + payload outputs , perhaps someone has some insight there, wouldn't be surprised if I'm overlooking some issues that makes this more complicated than I'm imagining.

Mike

On Sat, Aug 1, 2020 at 3:48 PM Cameron Matson <ncmatson95@gmail.com> wrote:

Hi everyone,

This might be more of a general digital communication question, so forgive me if this is inappropriate for this list, but I'm hoping you can provide some insight w.r.t the implementation.  

I'm using the architecture from the packet_tx/rx examples (https://www.gnuradio.org/doc/doxygen-v3.7.13.4/page_packet_comms.html I am using 3.7) to send packet data wirelessly between two USRP N310s.  I'm using the repetition encoder and BPSK for both the header and the payload.  The receiver is correctly detecting the packets, and the headers match exactly to what was transmitted, so I believe detection parts of the flowgraph (amplitude, timing, phase estimation and correction) are working properly, but there are significant bit errors in the payload.  I've observed two things happening:

1. The first 8-9 bytes will be correct and then it appears to "drop" a bit, and the remaining bits will be off by one to the tx data.  This "dropping" could happen a few times per message.

2. The entire rx payload will be the complement of the tx data.

These two things could happen together or independently.

For the first effect, it seems like the sample rate is not lining up with the edges of the symbols, or maybe a slight offset between the true sample rates of the tx and rx.  But the header is detected and decoded perfectly consistently; it's only in the payload that these "drops" occur.  I'm not sure why the second would happen.

Can you think of anything in the blocks of the packet_tx/rx examples that I can adjust to help with either of these problems?  Or just in general what might be going on?

Thank you for your time,

Cameron