Re: [Discuss-gnuradio] Odd Behavior

[Brian Padalino]

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

On Mon, Dec 15, 2014 at 6:22 PM, Richard Bell <address@hidden> wrote:
> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>