 All-

I was hoping I could get some advice on what is a good block-design
strategy
for the following problem.

I have two streams of complex samples coming in. I want a block or
sequence
of blocks which outputs the cosine of the phase difference between the
two
input streams.

If we could assert that both input streams are unit length, then one way
to
do it would be to conjugate one stream, then complex multiply the two
together, then take the real part of the output. But if the input
streams
are NOT normalized, then the product will likely not be unit length
either,
and this won’t work.

We could try and normalize the complex product, but the universe
explodes if
it has length 0 (divide by 0). Also, this would require a slow sqrt (?)

Is the best approach to just get the phase of the complex product via
fast_atan2f, then take the cos of that?

Do any basic math/trig functions (cos, atan2, sqrt, etc) exist at the
python
block level, or do I have to delve into C to use them?
Makefiles are scary Steven C. wrote:

We could try and normalize the complex product, but the universe
explodes if it has length 0 (divide by 0).

What do you want the answer to be in this case? You will only have a
zero length vector from the conjugate multiplication if one of the
original vectors is also zero length. So the angle difference between
them is undefined anyway.

One approach then would be to ensure this never happens, i.e., add a
small epsilon to each input stream, and make epsilon small enough to not
sufficiently impact the results for “typical” input values. Normalizing
the conjugate product will then give you the cosine as the real value,
as you mentioned. Or, you could just divide the abs value into the real
value of the product, and avoid the extra calculation of the normed
imaginary part which you are going to throw away.

You could do this from Python with existing blocks.

Do any basic math/trig functions (cos, atan2, sqrt, etc) exist at the
python block level, or do I have to delve into C to use them?
Makefiles are scary You’ll pretty much need write your own low-level block if you want to
use this approach.

An alternative is to step back and look at the bigger picture of what
you are trying to do.

What do you need the cosine of the angle difference for? Does it really
need to be normalized? Is there a way to use the conjugate product
itself downstream in your calculation? That is, can you “stay” in the
rectangular representation instead of going to sin/cos?

Is there a way you can guarantee the input streams never have zero norm?

Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Steven C. wrote:

do it would be to conjugate one stream, then complex multiply the two
together, then take the real part of the output. But if the input streams
are NOT normalized, then the product will likely not be unit length either,
and this won’t work.

We could try and normalize the complex product, but the universe explodes if
it has length 0 (divide by 0). Also, this would require a slow sqrt (?)
If your input streams have a rather stable amplitude you could put a
slow AGC in front of them to normalize.
You shoudl make sure that the vectors are length 1.0.
I remember using this trick and that I had to set the reflevel of the
agc to 1/srt(2) (in stead of 1.0) or something like that to get it to
output vectors of length 1.0.

This will however not be as accurate as actually doing the slow sqrt()
for every sample.

Is the best approach to just get the phase of the complex product via
fast_atan2f, then take the cos of that?
I am working on an SSE optimized version of atan2.
It is not fully checked and so not ready for primetime but maybe this
would work for you.
How much in a hurry are you?

Do any basic math/trig functions (cos, atan2, sqrt, etc) exist at the python
block level, or do I have to delve into C to use them?
Makefiles are scary No they are not Get them to know better and they will be your friends.

On 10/18/07, Johnathan C. [email protected] wrote:

One approach then would be to ensure this never happens, i.e., add a
small epsilon to each input stream, and make epsilon small enough to not
sufficiently impact the results for “typical” input values. Normalizing
the conjugate product will then give you the cosine as the real value,
as you mentioned. Or, you could just divide the abs value into the real
value of the product, and avoid the extra calculation of the normed
imaginary part which you are going to throw away.

Thanks for the replies guys. The above is the approach I went with.
It seems to work well, and gave a further BER improvement to my GMSK
demod
experiments.

For those interested, here is how I’m using it in the context of GMSK
demod:

``````    self.kc = gr.kludge_copy(gr.sizeof_gr_complex)
self.delay = gr.delay(gr.sizeof_gr_complex,
``````

2self._samples_per_symbol) #2T delay
self.conj = gr.conjugate_cc()
self.mult = gr.multiply_cc()
self.c2mag = gr.complex_to_mag()
self.c2f = gr.complex_to_float()
self.rescaler = gr.divide_ff()
samp_per_sec = samples_per_symbol * sym_per_sec
pre_cr_filt_bw = sym_per_sec
pre_cr_filt_bt
pre_cr_filt_taps = gr.firdes.low_pass(1.0, samp_per_sec,
pre_cr_filt_bw, pre_cr_filt_tr*samp_per_sec, gr.firdes.WIN_HAMMING)

``````    self.pre_cr_filt = gr.fir_filter_fff(1, pre_cr_filt_taps)

# the clock recovery block tracks the symbol clock and resamples
``````

as
needed.
# the output of the block is a stream of soft symbols (float)
self.clock_recovery = gr.clock_recovery_mm_ff(self._omega,
self._gain_omega,
self._mu,
self._gain_mu,

self._omega_relative_limit)

``````    # slice the floats at 0, outputting 1 bit (the LSB of the output
``````

byte) per sample
self.slicer = gr.binary_slicer_fb()

``````    [...]

# Connect & Initialize base class
self.connect(self, self.kc, self.delay, self.conj, (self.mult,
``````

0))
self.connect(self.kc, (self.mult, 1))
self.connect(self.mult, self.c2f, (self.rescaler, 0))