Re: [Discuss-gnuradio] Strategy advice
On 10/18/07, Johnathan Corgan [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, 2*self._samples_per_symbol) #2T delay self.conj = gr.conjugate_cc() self.mult = gr.multiply_cc() self.c2mag = gr.complex_to_mag() self.safety_add = gr.add_const_ff(0.001) self.c2f = gr.complex_to_float() self.rescaler = gr.divide_ff() self.sub = gr.add_const_ff(-self._decision_threshold) 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)) self.connect(self.mult, self.c2mag, self.safety_add, (self.rescaler, 1)) self.connect(self.rescaler, self.pre_cr_filt, self.sub, self.clock_recovery, self.slicer, self) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strategy advice
Steven Clark wrote: 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 (?) 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Strategy advice
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 :( ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strategy advice
Steven Clark 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 Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
