Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
On Tue, Feb 21, 2012 at 1:06 PM, Florian Schlembach < florian.schlemb...@tu-ilmenau.de> wrote: > There is a coarse and a fine frequency offset correction. The fine >> correct makes sure that the subcarrier is centered in the bin; the >> coarse adjusts for an integer number of subcarriers off from the center >> frequency. By default, the OFDM receiver will correct for some number of >> subcarrier bins (it's either +/-5 or +/-10; I can't remember). If your >> radios have a frequency offset that is greater than the maximum number >> of subcarriers specified here, the receiver cannot receive the symbols >> correctly. >> > > How about the fine frequency offset correction? How can I turn it on? For > instance, how do I have to modify the benchmark/tunnel scripts in order to > do that? it is on by default. You can't receive OFDM unless you are doing that kind of correction; the ICI would be awful if you didn't. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
Although using the same device to check on said carrier as is transmitting it leads to compounding error in one direction or t'other. Best to use another device (preferrably a lab spectrum analyser) to check the offset. -Marcus On Tue, 21 Feb 2012 12:56:30 -0500, Tom Rondeau wrote: > On Tue, Feb 21, 2012 at 11:35 AM, Florian Schlembach wrote: > >>> Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it >>> just with the OFDM transmitter? >> What is this tool doing? Transmitting a sine and checking the offset. Sorry, for the moment I have no possibilitie to check that. > > Yes. > >>> 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. >> >> @Tom >> does that mean that there is only a coarse frequency correction implemented? How could I overcome the offset in the easiest way? Checking it by usrp_siggen.py and adjust in manually or are there some smart correction algorithms implemented? > > There is a coarse and a fine frequency offset correction. The fine correct makes sure that the subcarrier is centered in the bin; the coarse adjusts for an integer number of subcarriers off from the center frequency. By default, the OFDM receiver will correct for some number of subcarrier bins (it's either +/-5 or +/-10; I can't remember). If your radios have a frequency offset that is greater than the maximum number of subcarriers specified here, the receiver cannot receive the symbols correctly. > > Yes, you can transmit a tone using uhd_siggen.py to fine out a rough estimate of the frequency offset and adjust either the transmitter or receiver based on this number. > > Tom Links: -- [1] mailto:florian.schlemb...@tu-ilmenau.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
There is a coarse and a fine frequency offset correction. The fine correct makes sure that the subcarrier is centered in the bin; the coarse adjusts for an integer number of subcarriers off from the center frequency. By default, the OFDM receiver will correct for some number of subcarrier bins (it's either +/-5 or +/-10; I can't remember). If your radios have a frequency offset that is greater than the maximum number of subcarriers specified here, the receiver cannot receive the symbols correctly. How about the fine frequency offset correction? How can I turn it on? For instance, how do I have to modify the benchmark/tunnel scripts in order to do that? Yes, you can transmit a tone using uhd_siggen.py to fine out a rough estimate of the frequency offset and adjust either the transmitter or receiver based on this number. Thanks, I will try that next days. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
On Tue, Feb 21, 2012 at 11:35 AM, Florian Schlembach < florian.schlemb...@tu-ilmenau.de> wrote: > Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it >> just with the OFDM transmitter? >> > > What is this tool doing? Transmitting a sine and checking the offset. > Sorry, for the moment I have no possibilitie to check that. Yes. > > 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. > > @Tom > does that mean that there is only a coarse frequency correction > implemented? How could I overcome the offset in the easiest way? Checking > it by usrp_siggen.py and adjust in manually or are there some smart > correction algorithms implemented? > There is a coarse and a fine frequency offset correction. The fine correct makes sure that the subcarrier is centered in the bin; the coarse adjusts for an integer number of subcarriers off from the center frequency. By default, the OFDM receiver will correct for some number of subcarrier bins (it's either +/-5 or +/-10; I can't remember). If your radios have a frequency offset that is greater than the maximum number of subcarriers specified here, the receiver cannot receive the symbols correctly. Yes, you can transmit a tone using uhd_siggen.py to fine out a rough estimate of the frequency offset and adjust either the transmitter or receiver based on this number. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
So I just did: (1) UHD: git pull, redo-cmake, build, install, uninstall, install (2) GNU Radio: git pull, redo-cmake, build install, uninstall (3) UHD: uninstall (4) "cd /usr/local" and remove all cruft (5) UHD: delete cmake directory, redo-cmake, build, install (6) GNU Radio: delete cmake directory, redo-cmake, build, install (7) download latest UHD images, and install them So, I think I'm being thorough in using the most up-to-date versions of UHD and GNU Radio, and also not having cruft around. I will admit that I didn't do a fresh GIT clone of either UHD or GNU Radio. Even with all that I get the same results -- that Tx is off by 1 MHz. I guess next I'll try a fresh clone of UHD and GNU Radio, and see if that matters. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just with the OFDM transmitter? What is this tool doing? Transmitting a sine and checking the offset. Sorry, for the moment I have no possibilitie to check that. > 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. @Tom does that mean that there is only a coarse frequency correction implemented? How could I overcome the offset in the easiest way? Checking it by usrp_siggen.py and adjust in manually or are there some smart correction algorithms implemented? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
On Feb 21, 2012, at 10:05 AM, Tom Rondeau wrote: > Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just > with the OFDM transmitter? I do see it with uhd_siggen.py. Didn't know about that utility; cool! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
On Tue, Feb 21, 2012 at 10:00 AM, Michael Dickens 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
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
On Tue, Feb 21, 2012 at 9:14 AM, Michael Dickens 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
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. 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Benchmark Tx Issue?
I highly suspect it's user error :) but I'm truly at a loss right now as to the error. Michael, 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 BRs, Florian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM Benchmark Tx Issue?
I've been playing with the gr-digital OFDM benchmark, Tx -> Rx, and have an odd issue that seems to be coming from within GNU Radio itself, not UHD. My setup is: Mac OS X 10.6.8, latest UHD and GNU Radio from their respective GIT masters, XCode 3.2.3 (gcc 4.2.1). I'm using 2 USRP1's, each with an XCVR2450 (in slot A, using antenna J1), connected to my MacBook Pro (via USB 2.0). 'uhd_usrp_probe' and 'uhd_find_devices' both work correctly in finding and identifying both USRP1's. 'uhd_fft.py' seems to work After installing GNU Radio into /usr/local, if I do in one terminal (or, the equivalent in GRC), with XXX correct: pushd /usr/local/share/gnuradio/examples/digital/ofdm ./benchmark_rx.py -a serial=XXX --spec A:0 -A J1 -f 5e+9 --snr 10 and in another (or, the equivalent in GRC), with YYY correct: pushd /usr/local/share/gnuradio/examples/digital/ofdm ./benchmark_tx.py -a serial=YYY --spec A:0 -A J1 -f 5e+9 The Rx side shows nothing at all. So, I then used 'uhd_fft.py' to view the spectrum, and it looks like the Tx (or, Rx) is off by quite a bit -- high by ~1 MHz. So, correcting via: ./benchmark_tx.py -a serial=YYY --spec A:0 -A J1 -f 4.999e+9 works quite well, with most of the packets being Rx'd correctly. I've verified that swapping XXX and YYY has the same results, so it doesn't seem to matter which is doing Rx and which Tx. I then created my own program in C/C++ to do a Tx using the UHD library, making a multi-usrp and setting its various parameters as per the above CLIs, then transmitting a real (complex part all 0) sinusoid of a known frequency, and it displays (using 'uhd_fft.py') correctly centered just off 5 GHz (like, maybe 1 kHz off, which is within device tolerance). I've looked through the benchmark's codes (mostly the Python parts, but also some of the blocks in C++), and nothing pops out as an obvious issue. I tried "rm -rf" in /usr/local and my build directories (UHD and GNU Radio), then rebuilding and reinstalling both UHD and GNU Radio, but with the same results. Can anyone tell me what I'm not doing correctly, or suggest further tests to track down the issue? I highly suspect it's user error :) but I'm truly at a loss right now as to the error. Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
