Odd Behavior

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

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. [email protected]

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. [email protected]

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