discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Odd Behavior


From: Richard Bell
Subject: Re: [Discuss-gnuradio] Odd Behavior
Date: Mon, 15 Dec 2014 15:22:26 -0800

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 Bell <address@hidden> wrote:
 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 Bell <address@hidden> wrote:
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]