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 >> >
