"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 <[email protected]> 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 <[email protected]> > wrote: > >> Forgot to reply to the list. >> >> ---------- Forwarded message --------- >> From: Cameron Matson <[email protected]> >> Date: Mon, Aug 3, 2020 at 10:55 AM >> Subject: Re: errors in packet payload with n310s >> To: Michael Carosino <[email protected]> >> >> >> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> >>>
