On Tue, Feb 21, 2012 at 9:14 AM, Michael Dickens
<address@hidden> wrote:
Hi Florian - Interesting observation about better reception when using larger bandwidths. I tried it out, and yes indeed they do seem better at 1 MS/s compared with 250 or 500 kS/s -- meaning that more packets are received correctly at the higher rate than the lower rates. I didn't try > 1 MS/s yet, but I will later. I need to review my OFDM to get a better clue as to why this might be the case.
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.
Though this is interesting and useful, my problem wasn't the packet error rate.
My issue was that the Tx center frequency was 1 MHz high with a center frequency of 5 GHz [1], no matter which USRP1 I used for Tx, when using GNU Radio -> UHD. When I wrote my own C++ program to use UHD for doing Tx of a real sinusoid -- "real" so as to see both the + and - spikes, so as to be able to determine where the center frequency is -- everything centered correctly when I set the UHD frequency to 5 GHz [2].
I don't have time right now to investigate further. Mostly throwing this out to see if anyone else had encountered it. - MLD
[1] 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.
[2] The offset was ~1 kHz, or ~0.2 ppm, which is well within hardware spec.
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.
Tom
On Feb 20, 2012, at 12:23 PM, Florian Schlembach wrote:
> we encountered a very similar issue and spent already a lot of time on that. Configuration is the same except we are using an USRP2 though.
>
> We also did not receive anything at the RX side although the spectrum looked quite good as we have checked that via usrp_fft.py.
> Ultimately, we found out that it was about the sampling rate. We were able to receive something with a sampling rate (respective bandwidth ) from 1.5 MSamples/s, better 2 MS/s.
> We are assuming that this might be a decimation rate issue. We facing the same problems with both a XCVR2450 and an RFX daugherboards. We checked whether lower sampling rates are working with both daughterboards (with another SDR implementation called Iris, also uses UHD) and they do! Thus, this might eventually be a problem of GNU Radio.
>
> Could you check whether you are receiving something with higher sampling rates? Just invoke your benchmark scripts with a higher bandwidth, e.g. -W 2M