Re: [Discuss-gnuradio] decode problem in benchmark

[Tom Rondeau]

On Mon, Jul 15, 2013 at 4:50 PM, yeran <address@hidden> 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