... 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 <[email protected]> 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 <[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 >>>>> >>>>
