# Decode problem in benchmark **URL:** \ **Category:** GNU Radio\ **Created:** [July 15, 2013, 10:51pm UTC](https://www.ruby-forum.com/t/decode-problem-in-benchmark/245803 "2013-07-15T22:51:55Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [July 15, 2013, 10:51pm UTC](https://www.ruby-forum.com/t/decode-problem-in-benchmark/245803/1 "2013-07-15T22:51:55Z")
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 ---
**Author:** ![yeran](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/e79b87/32.png) [@yeran](https://www.ruby-forum.com/u/yeran)\ **Post date:** [July 17, 2013, 6:53pm UTC](https://www.ruby-forum.com/t/decode-problem-in-benchmark/245803/2 "2013-07-17T18:53:45Z")
On Mon, Jul 15, 2013 at 4:50 PM, yeran [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![yeran](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/e79b87/32.png) [@yeran](https://www.ruby-forum.com/u/yeran)\ **Post date:** [July 17, 2013, 8:23pm UTC](https://www.ruby-forum.com/t/decode-problem-in-benchmark/245803/3 "2013-07-17T20:23:45Z")
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! ---
**Author:** ![yeran](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/e79b87/32.png) [@yeran](https://www.ruby-forum.com/u/yeran)\ **Post date:** [July 18, 2013, 5:35am UTC](https://www.ruby-forum.com/t/decode-problem-in-benchmark/245803/4 "2013-07-18T05:35:56Z")
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: removed\_email\_address@domain.invalid To: removed\_email\_address@domain.invalid; removed\_email\_address@domain.invalid 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!