Decode problem in benchmark

GNU Radio
1

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

2

On Mon, Jul 15, 2013 at 4:50 PM, yeran [email protected] wrote:

this mapping result, 1 or 0, is written into rx_unpack.8b.
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

3

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!

4

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: [email protected]
To: [email protected]; [email protected]
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!