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 >
