On Tue, Feb 21, 2012 at 10:00 AM, Michael Dickens <m...@alum.mit.edu> wrote:
> On Feb 21, 2012, at 9:44 AM, Tom Rondeau wrote: > > It's because with the larger bandwidth, the subcarriers, too, have a > larger bandwidth. The coarse frequency correction is only set to look at so > large an offset based on a number of subcarriers (+/-5 or 10), so now with > the same frequency offset, 5 (or 10) carriers is a larger frequency span to > check. > > Ah; yes. That makes sense. My mind is thrashing with multi-thread > dilemmas, not signal processing, right now. > > >> 1 MHz off at 5 GHz is 200 ppm (yes?). IIRC a reasonable spec on these > boards is 5-10 ppm. So, > 10x off the spec? I doubt it. My guess is > it's something in GNU Radio that wasn't fixed when the benchmarks were > transitioned from gr-usrp* to UHD. > > > > I think this is a known problem with the XCVR that has been fixed. Make > sure you have the most up-to-date master branch of both the UHD and GNU > Radio. > > They were both the most recent as of yesterday. I'll update right now & > see if that helps, but I'm doubtful since none of the commits since > yesterday seem to impact the behavior of the XCVR. I'll also remove any > cruft in /usr/local before re-installing. More later. - MLD No, this would have been fixed weeks/months ago, so updating today won't help. Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just with the OFDM transmitter? Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
