Re: [Discuss-gnuradio] decode problem in benchmark--NCO?

[yeran]

Hi,

I looked into the digital_constellation_receiver_cb.cc, and find out that the NCO value is for derotating the current sample. But I still don't get how the NCO is calculated, and where the d_phase is from and how it changes with each bit.

Do you have any ideas on that?

Thanks a lot!

Ada

---

From: address@hidden
To: address@hidden; address@hidden
Subject: RE: [Discuss-gnuradio] decode problem in benchmark
Date: Wed, 17 Jul 2013 18:22:37 +0000

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: address@hidden
> Date: Wed, 17 Jul 2013 12:51:24 -0400
> Subject: Re: [Discuss-gnuradio] decode problem in benchmark
> To: address@hidden
> CC: address@hidden
>
> 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