# Odd Behavior **URL:** \ **Category:** GNU Radio\ **Created:** [December 15, 2014, 7:29pm UTC](https://www.ruby-forum.com/t/odd-behavior/233458 "2014-12-15T19:29:38Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [December 15, 2014, 7:29pm UTC](https://www.ruby-forum.com/t/odd-behavior/233458/1 "2014-12-15T19:29:38Z")
Problem: Real and Imaginary outputs of CPFSK sometimes seem flipped in the transmitter. I’m using the CPFSK block to modulate for a binary FSK radio. All that I reference here is in the transmitter. There are 3 input paramaters for the block: k (modulation index), A (Amplitude) and N (Samples/Symbol). The relationship between input and output of the CPFSK block is shown below and found in the source code: out[n] = A\*exp( j \* k \* pi \* 1/N \* n \* input[n] ) where input[n] = +1 or -1 is the input data to the block. Now with that all setup, here is the odd behavior. Since input[n] is only +1 and -1, I expect the real part of the output to remain unchanged and the input changes, because cos(-x) = cos(x) and I expect the imaginary part to flip signs as the input changes because sin(-x) = -sin(x). What I see is sometimes the cos will be flipping signs with the sin remaining constant. It is as though the inphase and quadrature arms were reversed. I am looking at the real and imaginary output of the CPFSK block in the transmitter. Because we are in the transmitter, there are no channel effects or synchronization effects that come into play to cause this. Does anyone know what could cause this? v/r, Rich ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [December 15, 2014, 11:22pm UTC](https://www.ruby-forum.com/t/odd-behavior/233458/2 "2014-12-15T23:22:34Z")
I have an update to this behavior. It is still not fixed. I was using a separate multiply block after the CPFSK block to control the amplitude. There was no good reason for this, it’s just how I set it up the first time. I decided to remove that multiply block and use the built in amplitude parameter to control the output gain. This has reduced the accumulating phase offset that creeps into the CPFSK output, but not completely. Overtime, the real part of the output will still begin to change phase. This leads me to believe there is some kind of thread timing issue that is allowing a phase offset to creep into the CPFSK output on the transmitter side. I’m including a screenshot of my transmitter. Not much going on here. I am also including a screenshot of the real and imaginary time series when the program first starts and after a few minutes of run time. Rich On Mon, Dec 15, 2014 at 10:28 AM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [December 16, 2014, 12:23am UTC](https://www.ruby-forum.com/t/odd-behavior/233458/3 "2014-12-16T00:23:21Z")
I think I want to back off this claim of odd behavior. The more I think about general CPFSK, the more I’m convincing myself that total accumulated phase will be changing, depending on the ratio of -1’s to 1’s. So seeing the real part slowly change phase should not be a worry, I think? Rich On Mon, Dec 15, 2014 at 2:21 PM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [December 16, 2014, 1:14am UTC](https://www.ruby-forum.com/t/odd-behavior/233458/4 "2014-12-16T01:14:52Z")
Unless your CPFSK is defined such that each bit is +/-90 degrees, then you’re right. If you are setup to have +/-90 degree phase shifts per bit, then each bit transition time should fall on 0, 90, 180 or 270 exactly. No slight phase shifts one way or the other in the transmitter. My guess is that there is just some precision rounding happening and after a few minutes with hundreds of thousands of phase increments, you’ve just accumulated a decent amount of error. But this is just a guess. Any actual system will need to track any sampling rate differences and frequency offsets, so it’s probably negligible - though it is also worth while to try to investigate and see where the offset is coming from. Brian