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 <ncmatso...@gmail.com> wrote: > Forgot to reply to the list. > > ---------- Forwarded message --------- > From: Cameron Matson <ncmatso...@gmail.com> > Date: Mon, Aug 3, 2020 at 10:55 AM > Subject: Re: errors in packet payload with n310s > To: Michael Carosino <m.caros...@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.caros...@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 <ncmatso...@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 >>> >>
