On Mon, Jul 15, 2013 at 4:50 PM, yeran <yeran0...@hotmail.com> wrote: > Hi everyone, > > I have a question about benchmark decoding. I'm using bpsk mod and demod. > > In order to understand what's happening in the demodulation process, I added > a file sink after time_recov block and after unpack block respectively. > According to my understanding, the receiver block does the mapping and > decision making process. It maps the complex number in rx_time_recov.32fc to > 1 if the complex number is bigger than zero. It will map the complex number > in rx_time_recov.32fc to 0 if the complex number is smaller than zero. And > this mapping result, 1 or 0, is written into rx_unpack.8b. > > However, in real experiment, I found wired result. Sometimes the mapping is > using the algorithm as above, sometimes it is totally the opposite way. > (complex number in rx_time_recov.32fc smaller than zero will be mapped as > 1). Even this algorithm is not the same within one packet. For instance, the > access code is mapped using one algorithm, and the payload is mapped the > other way. > > I don't understand why this is happening. Is there anything to do with the > phase error or anything? Can anyone give me some suggestions on how it > works? > > Thanks! > Ada
What you're seeing is the result of phase rotation due to a frequency offset. The tracking loops for frequency, timing, and phase have to search, acquire, and lock. In this process, by the time they are done, they are locked in a way that has any possible symmetrical rotation. For BPSK, you can have two rotations (0, 1 or 1, 0). For QPSK, you can have four possible rotations. There's nothing in the system that understands the right constellation to symbol map to correct for this. One reason why we use differential encoding by default since it doesn't care about this. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
