Hi, Tom
Thank you for your reply. Here is my problem.
Even though i have found some of the data in rx_time_recov.32fc were wrong, the
decoding result after block constellation_receiver_cb can still be correct. (I
trace back the data from rx_unpack.8b to rx_time_recov.32fc)
I read through the c++ file but i think the phase error has no contributions to
decision_maker_pe. The advance_loop() function in phase_error_tracking() only
records the error instead of updating this information to decision part. Am i
right about that?
So i dont understand how can the gnuradio itself get the correct decoding
result. do u have any clues about that?
Thanks!
> From: t...@trondeau.com
> Date: Wed, 17 Jul 2013 12:51:24 -0400
> Subject: Re: [Discuss-gnuradio] decode problem in benchmark
> To: yeran0...@hotmail.ciom
> CC: discuss-gnuradio@gnu.org
>
> 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
