Thanks Matt, I understand the issue now and switching atan functions does indeed make the glitches go away.
Do you have a sense of how much slower the regular atan2f function is than gr_fast_atan2f? If the performance hit isn't too bad, I might leave it in for peace of mind. Regarding excessive oversampling: I agree that 64, 128, etc. samples per symbol is pretty ridiculous, I was just seeing how the issue scaled with sps. What is the best strategy when you want to rx a signal at a very slow symbol rate? Max decimation (256?) on the USRP, then decimate/filter some more in software? As an arbitrary example, symbol rate 7812.5 sym/sec: have the usrp decimate by 256 and you're still at 32 samp/sym. What is the best way to partition decimation between hw and sw? Which sw blocks are ideal for this? On 9/21/07, Matt Ettus <[EMAIL PROTECTED]> wrote: > > Steven Clark wrote: > > Hi all- > > please look at this sequence of eye diagrams: > > http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches > > > > These are from a gmsk mod/demod pair, showing the output of the TX's > > gaussian filter (blue) overlaid with the output of the RX's fmdemod > > (red). BT = 0.35. > > > > At 8 samples per symbol, everything looks ok. Red is pretty much right > > on top of blue, as we'd expect. > > As I increase samples per symbol, however, something strange happens, > > shown in plot sequence. The RX's fmdemod output gets successively more > > "glitchy". > > > > This might be because of the use of gr_fast_atan2f. This function is an > approximation used in order to speed things up since the real atan2f is > slow. Could you try replacing line 58 of gr_quadrature_demod_cf: > > out[i] = d_gain * gr_fast_atan2f(imag(product), real(product)); > > > with > > out[i] = d_gain * atan2f(imag(product), real(product)); > > and see if the problem persists? When doing very high oversampling like > you are, the difference in phase angles between successive samples is > very small. If the error when doing the lookup table interpolation > changes a bit when crossing over the endpoints of the table, you could > see this sort of effect. You'll notice that the errors are always at > the same point in the diagram, around the mid-level, which is where the > frequency is lowest. > > Matt > > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
