RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt Thanks so much for your help. I tried your latest suggestion, and this gets my frequency offset between Tx and Rx down to a mere 1 Hz. This is much better and should make my testing considerably simpler. Cheers Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Wednesday, 18 August 2010 1:09 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 09:22 PM, Ian Holland wrote: Please disregard my last. I must have got something wrong in my testing. It now compiles, but it seems I need to use txrx_xcvr.bin instead of txrx.bin with the latest git trunk. Please correct me if this is wrong (note I have XCVR2450 as my daughterboard). This is correct. Due to the size of the code, the xcvr was split out to its own file. Also, you are right about the prescaler. Nonetheless, I still seem to get a time varying frequency offset between a transmitted and received BPSK waveform, when using the same local oscillator of 36 MHz at each end. In fact, about every million samples, this frequency offset disappears, then comes back getting larger, then smaller and disappears again about 1 million samples later. Is this expected when using a reference different to 10 MHz? When I have used two USRP2s both locked to a 10 MHz reference, I never saw this problem. No, you should not see that. It sounds like it is not locked, and I think the reason is loop bandwidth. The original setup is for a 10 MHz compare frequency, and you are using a 1 MHz compare frequency. This will mess up the loop dynamics by dividing the loop bandwidth by 10. The greatest common divisor of 100 MHz and 36 MHz is 4 MHz, so I would use that for the compare frequency. Then also increase the charge pump current to the maximum. That should bring you closer to the original loop bandwidth. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: Unable to build firmware binary
Hi All Sorry - it turns out I was missing the Microblaze tools on the machine I used to do the make. I have since fixed the problem. Ian. From: Ian Holland Sent: Monday, 16 August 2010 2:50 PM To: 'discuss-gnuradio@gnu.org' Subject: Unable to build firmware binary Hi I have recently made some changes to the usrp2 firmware, and tried to build according to USRP2 User FAQ. As far as I could tell from the aforementioned FAQ, this should have resulted in a file txrx.bin being created, that I can download to the SD card for the USRP2. However, in the first instance, the build failed due to some unlocated files in the linking stage. Hence, I did a fresh make bootstrap/configure/make etc. from the top directory, and the make succeeded but I still get no txrx.bin Finally, I tried to uninstall old make and clean git as per instructions on gnu radio website. Still, I do not get the txrx.bin when I make from gnuradio/usrp2 directory. Can anyone suggest what I might be doing wrong or how to fix this problem? Thanks Ian. This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device-config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device-config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. Best Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Saturday, 14 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... gnuradio/usrp2/firmware/lib/clocks.c, starting at line 40. You probably want to read the AD9510 datasheet to help with selecting values. Matt On 08/13/2010 12:34 AM, Ian Holland wrote: Hi I have read on the FAQ that is possible to change the external reference frequency for the USRP2 from 10 MHz to another value simply by changing one line in the firmware. However, I have as yet been unable to locate the actual source file in which I need to make this change, and what the name of this variable is. Could someone please let me know? Many Thanks Ian. This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device-config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device-config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi Matt Further to below, I tried your suggestion, and still it didn't work. In fact, I have now found that the only thing that does work now is to use a pre-compiled binary that I downloaded for txrx.bin (since recompiling with the original gnuradio source code didn't work). This suggests indeed the problem is either the Microblaze tools I have (since recompiling with the original gnuradio source code didn't work) or that the version of source I had (from March 21, 2010) was corrupt to begin with. However, I even tried updating to the latest git via git pull, and tried to remake using the original clock settings. Still, it doesn't work. Hence I suspect the microblaze tools as you suggested. I got the Microblaze tools from the gnuradio website. I would have though these should work fine, but perhaps not. Is there another source you can suggest? Best Regards Ian. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 9:24 AM To: 'Matt Ettus' Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device-config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device-config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...
Please disregard my last. I must have got something wrong in my testing. It now compiles, but it seems I need to use txrx_xcvr.bin instead of txrx.bin with the latest git trunk. Please correct me if this is wrong (note I have XCVR2450 as my daughterboard). Nonetheless, I still seem to get a time varying frequency offset between a transmitted and received BPSK waveform, when using the same local oscillator of 36 MHz at each end. In fact, about every million samples, this frequency offset disappears, then comes back getting larger, then smaller and disappears again about 1 million samples later. Is this expected when using a reference different to 10 MHz? When I have used two USRP2s both locked to a 10 MHz reference, I never saw this problem. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 11:33 AM To: Ian Holland; Matt Ettus Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt Further to below, I tried your suggestion, and still it didn't work. In fact, I have now found that the only thing that does work now is to use a pre-compiled binary that I downloaded for txrx.bin (since recompiling with the original gnuradio source code didn't work). This suggests indeed the problem is either the Microblaze tools I have (since recompiling with the original gnuradio source code didn't work) or that the version of source I had (from March 21, 2010) was corrupt to begin with. However, I even tried updating to the latest git via git pull, and tried to remake using the original clock settings. Still, it doesn't work. Hence I suspect the microblaze tools as you suggested. I got the Microblaze tools from the gnuradio website. I would have though these should work fine, but perhaps not. Is there another source you can suggest? Best Regards Ian. -Original Message- From: Ian Holland Sent: Tuesday, 17 August 2010 9:24 AM To: 'Matt Ettus' Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Changing external reference frequency with USRP2... Hi Matt I will try this, though given P = 2, I was under the impression the resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I have B = 50. At least, that is what the equation in the datasheet suggests. Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 17 August 2010 2:15 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Changing external reference frequency with USRP2... On 08/16/2010 12:21 AM, Ian Holland wrote: Thanks Matt I tried to change to get the external reference frequency to be 36 MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I modified lines 43 and 85 respectively to the following: ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24); If you set R to 36 then your compare frequency is 1 MHz. A setting of B = 50 means you are trying to lock at 50 MHz, which won't work. The crystal is at 100 MHz, so you need to use B=100. This will cause you to be way off in frequency (maybe 100 to 150 ppm). It should still function, however. However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD card, I was no longer able to see an OFDM signal I had been transmitting from another SDR at 2.4 GHz. This occurred both when I had configured the receiving SDR to lock onto the 36 MHz reference (device-config_mimo(usrp2::MC_WE_LOCK_TO_SMA)) And when I configured the receiving SDR to use its internal reference (device-config_mimo(usrp2::MC_WE_DONT_LOCK)) Have I done something wrong in my modifications? If so, can you please suggest what I am doing wrong? According to the AD9510 datasheet I believe my changes should have been correct. If it doesn't work with either setting then it is likely your firmware is bad. Check to make sure you are using a good Microblaze compiler. Matt This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unable to build firmware binary
Hi I have recently made some changes to the usrp2 firmware, and tried to build according to USRP2 User FAQ. As far as I could tell from the aforementioned FAQ, this should have resulted in a file txrx.bin being created, that I can download to the SD card for the USRP2. However, in the first instance, the build failed due to some unlocated files in the linking stage. Hence, I did a fresh make bootstrap/configure/make etc. from the top directory, and the make succeeded but I still get no txrx.bin Finally, I tried to uninstall old make and clean git as per instructions on gnu radio website. Still, I do not get the txrx.bin when I make from gnuradio/usrp2 directory. Can anyone suggest what I might be doing wrong or how to fix this problem? Thanks Ian. This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi I have read on the FAQ that is possible to change the external reference frequency for the USRP2 from 10 MHz to another value simply by changing one line in the firmware. However, I have as yet been unable to locate the actual source file in which I need to make this change, and what the name of this variable is. Could someone please let me know? Many Thanks Ian. This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ 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
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric I was not running through a switch. I tried what you suggested, and can confirm that the CPUs are not being throttled. I have then discovered that for some reason I can only get the problem to occur on one of my two host PCs. I am trying to install the new Ubuntu (actually, the 64-bit version thereof) for the time being, after formatting the hard drive, and am hoping it will work on this PC afterwards. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Thursday, 13 May 2010 4:07 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Wed, May 12, 2010 at 04:34:36PM +0930, Ian Holland wrote: Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. Ian, I still suspect something in your host setup. Is the USRP2 connected directly to the host or does it go through a switch? If there's a switch in the path, please remove it. Note that the cpu throttling / clock scaling hypothesis would explain why it works better under higher load than lower load. Are you sure that your cpu isn't being throttled? When you're seeing the problem, try: $ grep 'cpu MHz' /proc/cpuinfo and see if all cores are running at full speed. E.g., Idling laptop (throttled back from 1.83GHz): [...@cyan ~]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 1000.000 cpu MHz : 1000.000 Server with cpu scaling disabled: [...@octo swig]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 Eric -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric Please find my answers inline below. Cheers Ian. What GNU Radio version are you using? git? tarball? Git - Taken from trunk on 25 March 2010. What kind of hardware are you running on? HP Intel Core 2 Duo - 2 x 2 GHz CPUs How much RAM is in the machine? 3513M (according to free -mt) What OS and distribution are you running? Ubuntu 9.10 What kernel version are you using? Release: 2.6.31-20-generic Version: #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (according to uname -v) What else is running on the machine? Netbeans 6.8, and System Monitor. What USRP firmware are you using? u2_rev3.bin and txrx.bin, which were taken from the latest versions as of 29 January 2010. What does $ sudo ethtool -a ethN report? Pause parameters for eth0: Autonegotiate: on RX:on TX:off ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Matt and Marcus. I understand it is indicating dropped packets, hence causing later ones to show up out-of-sequence. Re the processing, this occurs even with the usrp2_fft.py script as well. I don't think that does more processing for higher values of decimation factor, though please correct me if I am wrong here. Also, I am not doing any special filtering with my code, simply capturing raw complex samples, and comparing their magnitude to a threshold. Of course, once the threshold is crossed I do more computations, but these S's appear even while I am still listening. On the other hand, when I reduce the decimation factor, then I don't have this problem until I do my other processing, which then leads to lost packets due to excessive computational load. As such, I haven't found a value of decimation factor that I can use. Cheers Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 11 May 2010 9:46 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On 05/10/2010 04:54 PM, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? I don't know what exactly is happening here, as I have not seen this behavior, but I just want to clarify a little terminology. The S you are seeing indicates sequence number errors. While getting packets out of sequence would give this error, that isn't that is happening. The sequence number errors really indicate that you are dropping packets because you can't keep up. Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Large number of overflows...
Hi Matt Myself and a colleague have created a C++ equivalent for the same flowgraph, with realtime scheduling enabled. We still have overruns for data rates above 2 Mbps, even on a Core i7 machine. We will try and make a multi-threaded version to hopefully resolve this, since our version is only single-threaded at this stage. In regards to using GRC to create the flowgraph, how can I check if realtime scheduling is enabled, and/or enable realtime scheduling? Thanks Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Matt Ettus Sent: Thursday, 22 April 2010 4:15 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Large number of overflows... On 04/11/2010 09:22 PM, Ian Holland wrote: Hi All I am trying a modified example of the digital-bert routines, for communication between 2 USRP2s, and notice that I am getting a very large number of overflows () even with decimation rate at the receiver of 20, and 4 samples per symbol (sometimes even with 20 samples/symbol). If I don't get overflows (as has occurred when I used 20 for decimation as well as 20 for samples/symbol in one instance), I am able to capture the demodulated bits as ..., as expected for the example. However, with overruns, which seem to occur more for lower samples per symbol and/or lower decimation values, I get a large number of bit errors. My receiver flowgraph is of the form: USRP2 Source -- RRC Filter -- Costas Loop -- Mueller and Muller Synch -- Complex to Real -- Binary Slicer -- Descrambler -- File Sink. The transmitter flowgraph uses the same blocks as per digital-bert/transmit_path.py, but with a USRP2 sink. I am transmitting over-the-air, and clocks are not synchronised between Tx and Rx. I have a gigabit Ethernet link, and 2 x 2 GHz CPUs in my PC, which is running Ubuntu 9.10. Can anyone suggest why I am getting so many over-runs, and how I could get around this problem? These overflows indicate one of two things: - that your flowgraph is too slow to execute in real time on your computer - You haven't enabled realtime scheduling. Matt ___ 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
RE: [Discuss-gnuradio] Large number of overflows...
Thanks Marcus Actually, the only filtering I did in the C++ version is for the MM clock recovery, i.e. in interpolating to get the symbols based on imperfectly timed samples. In the GRC example, I also had an RRC filter, with 11*samples_per_symbol taps, but this didn't appear to be the bottleneck. In both applications, the Costas loop and the MM timing recovery tend to be the problem. I think multithreading the C++ application will benefit, but I am not sure it is splittable into multiple threads other than possibly 3, since the Costas loop and also the MM loop are recursive in nature. By the way, FFTs don't seem to be such a problem, I can even get lower decimation rates for that, but to do the Costas/MM seems to be the big killer. Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Marcus D. Leech Sent: Friday, 23 April 2010 1:48 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Large number of overflows... On 04/22/2010 07:56 PM, Matt Ettus wrote: I am pretty sure that what you are seeing is that your application is not keeping up. The USRP2 keeps sending data to the computer as fast as it generates it. The ethernet card DMAs it into some buffer in memory. Your app uses it and the driver then frees the buffer. If at some point the driver receives a frame and there is no buffer free for it then the packet will be dropped, and you'll see an S. S stands for sequence number error, which is how the system can tell that there is a dropped packet. It is an overrun occurring in the computer, not in the hardware. The hardware will not overrun. The best way to test what is happening is to run usrp2_fft.py. If you can run that at the same or higher sample rates than you are using in your application, then the driver is not the issue. My guess is that your computer will run without problem at decimation of 6 at worst, and more likely all the way down to 4. Your app is running at a decimation of around 12 or 16, so it is your app that can't keep up. Think of it this way -- the fastest Core i7 machines are 3.2 GHz. For a 2 Mbps signal, you only have 1600 cycles per data bit. Assuming you are using at least 2 samples per bit, you only have 800 cycles per sample to process them. This is certainly possible, but you will need to optimize your code. How long are your filters? Are you using FFT-based filters instead of convolution based? Is too much memory getting copied around? For some perspective, based on USRP1 data. My radio astronomy application runs fairly well at 10.6Msps, on a Core 2 Quad 9XXX (9770?) machine, with 8G of memory, and clocked at about 3.2GHz. My application does a 1Hz-resolution FFT over the data (that's a 10.6M point FFT!), computes the total power, and also does interference notch filtering, using a FFT filter, plus SETI analysis, pulsar folding, and transient detection. It can keep up, but all 4 cores are pretty busy! I think Matt's analysis is pretty close to the mark. One of the mistakes people make (that I've also made) is to specify FIR filters with very-narrow transition widths--that will cause a very long filter to be created. Relaxing the skirts on the filter can dramatically reduce CPU consumption. I typically use filter skirts that are roughly 20-25% of the total bandwidth of the filter. In many applications, very tight filtering isn't a requirement for decent performance of the downstream demodulation, particularly when link margins are reasonably good anyway. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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
RE: [Discuss-gnuradio] IQ imbalance...
Hi Matt Yes, -9 dBm is safe. Glad to know it was all safe re input levels. I have not seen the problem locking without trying a lower frequency. What if you try 5 GHz twice in a row? The problem with the not locking to 5G is very intermittent. A few times when it did occur, I tried your suggestion of trying 5G a second time: 2 out of 3 times, it locked the second time. The other time, it did not, but then trying 2.35G followed by 5G did then work. Regarding the other intermittent issue that appeared as IQ imbalance, I have swapped the USRP2/XCVR2450 pair used for transmit with the receive one, and haven't observed the issue since. It may still occasionally occur for the first pair, but this is a workaround for me. I am still confused as to why it occurred to begin with. Best Regards Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks Jonathon This clears things up a bit. By the way, the post I was referring to can be found at http://osdir.com/ml/discuss-gnuradio-gnu/2010-02/msg00098.html Maybe I misread the reply from Jason, but said reply seemed to suggest to me that a single sample per symbol should be used. Anyway, your response has cleared things up for me. Best Regards Ian. -Original Message- From: Johnathan Corgan [mailto:jcor...@corganenterprises.com] Sent: Tuesday, 13 April 2010 4:36 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... On Mon, Apr 12, 2010 at 22:11, Ian Holland ian.holl...@rlmgroup.com.au wrote: I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. The digital-bert example uses a self-synchronizing scrambler to generate a bit sequence that occupies the full baseband bandwidth of the channel. The scrambler/descrambler pair is insensitive to the phase ambiguity; however, this comes at the price of generating extra bit errors on the descrambled sequence for every bit error in the channel. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks, I wasn't 100% clear if there were some conditions for interchangability after Jonathon's reply, but it sounds like not. Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Jason Uher Sent: Wednesday, 14 April 2010 12:19 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... I notice in the digital-bert example (benchmark_rx.py and receive_path.py), the Costas loop actually occurs prior to the MM sampler, without being wrapped inside the mpsk_receiver: (lines 104-105 of http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-examples/python/digi tal-bert/receive_path.py) self.connect(self, self._agc, self._rrc, self._costas, self._mm, self._c2r, self._slicer, self._descrambler, self._ber) Are these operations generally interchangeable? Thanks Ian. My explanation pertained to the benchmark_rx; but Johnathan already said it doesnt matter in his first reply ;) Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. ___ 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
RE: [Discuss-gnuradio] IQ imbalance...
Hi Matt Can you please confirm by input level you are referring to the input to the transceiver daughterboard? I am using the XCVR2450, for over-the-air reception. The input level (to the XCVR2450 at the receiver) would have been roughly: Tx Power (max. 20 dBm as per http://www.ettus.com/downloads/er_ds_transceiver_dbrds_v5b.pdf) + Tx Ant. Gain (3dBi) - Free Space Loss (at least 46dB for 2m separation and 2.4 GHz freq.) + Rx Ant. Gain (14 dBi) As far as I can tell based on the above (presuming the 20 dBm transmit power is based on max. gain setting for the Transmitting XCVR2450), the largest signal I could have at the Rx port after the Rx antenna is: 20 + 3 - 46 + 14 = -9 dBm So, if this is the case, I presume all was safe regardless of the chosen Rx gain setting for the receiving daughterboard. Can you please confirm if this would be the case, as I am encountering inconsistent behaviour with my equipment (such as the unrepeatable error mentioned earlier, and occasional fails to lock at 5 GHz without first trying to lock to a much lower frequency). Thanks Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Monday, 12 April 2010 3:04 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] IQ imbalance... As long as the input level is in the safe range, having too much gain would probably not damage anything. On the WBX, however, too much gain with a strong but normally safe level might be a problem. Matt On 04/11/2010 05:01 PM, Ian Holland wrote: Hi Matt Having seen your reply, I realise I was not clear in my original post. At the time I observed this error, it was even at the output of the RRC filter, i.e. prior to the MM synch. and Costas loop. The strange thing is, now I am unable to repeat this problem. Instead, now I see clipping of both the I and Q components when I increase the Rx gain beyond a particular level. While on this matter, is there any risk of damaging the equipment by simply setting the Rx gain too high, or is clipping the only consequence? Ian -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Friday, 9 April 2010 11:37 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] IQ imbalance... On 04/08/2010 09:16 PM, Ian Holland wrote: Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? I'm not sure exactly what you're describing here, but I am pretty sure it is not what I would call IQ imbalance. IQ imbalance would show up before any frequency translation, so at the Costas loop output is not where you would see it. The purpose of a costas loop is to track the phase of the incoming signal. That means that the majority of the energy in a BPSK signal will be in I and little will be in Q when the loop is locked. The stronger the signal and the better the SNR, the smaller the Q amplitude will be relative to the I signal. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Spectrum at 1 GHz
Hi Umair I believe the decimation factor you have chosen is beyond the maximum allowed (I think, from memory this is 512, which is well less than 1M = 1 times 10^6). It seems you are trying to sample the passband signal to show a spectrum at 1 GHz, however a digital-down conversion is performed at the receiver, so you should see a signal at baseband. You should not need to use such a high sampling rate - ideally, Nyquist rate (based on the signal bandwidth when downconveted to baseband) will suffice. Regards Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Umair Naeem Sent: Monday, 12 April 2010 4:59 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Spectrum at 1 GHz I have a query regarding flow graph in GRC. I am trying to get spectrum from DBS_RX daughter board using GRC. I have used three blocks as USRP2 Source -- FFT Filter -- FFT Sink They have following parameters, USRP2 Source: Decimation 1M Frequency 1G Gain (dB) 0 FFT Filter: Decimation 1 Taps firdes.complex_band_pass(1.0, 3000, -0.05e3, 0.05e3, 5, firdes.WIN_HAMMING, 0) FFT Sink: Sample Rate 2K Baseband Frequency 1K FFT Size 512 Refresh Rate 30 I need to display shows frequency spectrum centered at 1 GHz. Since I am using decimation of 1M, the frequency is lowered down to 1K. I filter it using FFT bandpass filter with 100 Hz bandwidth. The fft sink shows spectrum at around 1 KHz. The problem is if I do not use decimation, the GRC seems to be very slow (may be processing 1 GHz at GHz sample rate is too much). I need to make a FFT plot showing spectrum at 1 GHz. How Can I accomplish this? Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. ___ 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
RE: [Discuss-gnuradio] Spectrum at 1 GHz
Hi Umair There is a setting in the USRP2 source block that lets you set the carrier frequency. This should be 1e9 (i.e. 1G). What is the signal you are trying to receive? Ian -Original Message- From: Umair Naeem [mailto:ar...@student.chalmers.se] Sent: Monday, 12 April 2010 8:22 PM To: Ian Holland Subject: RE: [Discuss-gnuradio] Spectrum at 1 GHz So If I need to see in the baseband region then what should be the parameters of USRP2 source for my case (i.e. Decimation and Frequency). Should I give 1 GHz in the frequency parameter or in the baseband region? Thanks for help... Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. From: Ian Holland [ian.holl...@rlmgroup.com.au] Sent: Monday, April 12, 2010 9:55 AM To: Umair Naeem; discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Spectrum at 1 GHz Hi Umair I believe the decimation factor you have chosen is beyond the maximum allowed (I think, from memory this is 512, which is well less than 1M = 1 times 10^6). It seems you are trying to sample the passband signal to show a spectrum at 1 GHz, however a digital-down conversion is performed at the receiver, so you should see a signal at baseband. You should not need to use such a high sampling rate - ideally, Nyquist rate (based on the signal bandwidth when downconveted to baseband) will suffice. Regards Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Umair Naeem Sent: Monday, 12 April 2010 4:59 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Spectrum at 1 GHz I have a query regarding flow graph in GRC. I am trying to get spectrum from DBS_RX daughter board using GRC. I have used three blocks as USRP2 Source -- FFT Filter -- FFT Sink They have following parameters, USRP2 Source: Decimation 1M Frequency 1G Gain (dB) 0 FFT Filter: Decimation 1 Taps firdes.complex_band_pass(1.0, 3000, -0.05e3, 0.05e3, 5, firdes.WIN_HAMMING, 0) FFT Sink: Sample Rate 2K Baseband Frequency 1K FFT Size 512 Refresh Rate 30 I need to display shows frequency spectrum centered at 1 GHz. Since I am using decimation of 1M, the frequency is lowered down to 1K. I filter it using FFT bandpass filter with 100 Hz bandwidth. The fft sink shows spectrum at around 1 KHz. The problem is if I do not use decimation, the GRC seems to be very slow (may be processing 1 GHz at GHz sample rate is too much). I need to make a FFT plot showing spectrum at 1 GHz. How Can I accomplish this? Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. ___ 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] Why no phase ambiguity in digital-bert...
Hi All I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Any help in these matters would be greatly appreciated. Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] IQ imbalance...
Hi Matt Having seen your reply, I realise I was not clear in my original post. At the time I observed this error, it was even at the output of the RRC filter, i.e. prior to the MM synch. and Costas loop. The strange thing is, now I am unable to repeat this problem. Instead, now I see clipping of both the I and Q components when I increase the Rx gain beyond a particular level. While on this matter, is there any risk of damaging the equipment by simply setting the Rx gain too high, or is clipping the only consequence? Ian -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Friday, 9 April 2010 11:37 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] IQ imbalance... On 04/08/2010 09:16 PM, Ian Holland wrote: Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? I'm not sure exactly what you're describing here, but I am pretty sure it is not what I would call IQ imbalance. IQ imbalance would show up before any frequency translation, so at the Costas loop output is not where you would see it. The purpose of a costas loop is to track the phase of the incoming signal. That means that the majority of the energy in a BPSK signal will be in I and little will be in Q when the loop is locked. The stronger the signal and the better the SNR, the smaller the Q amplitude will be relative to the I signal. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Large number of overflows...
Hi All I am trying a modified example of the digital-bert routines, for communication between 2 USRP2s, and notice that I am getting a very large number of overflows () even with decimation rate at the receiver of 20, and 4 samples per symbol (sometimes even with 20 samples/symbol). If I don't get overflows (as has occurred when I used 20 for decimation as well as 20 for samples/symbol in one instance), I am able to capture the demodulated bits as ..., as expected for the example. However, with overruns, which seem to occur more for lower samples per symbol and/or lower decimation values, I get a large number of bit errors. My receiver flowgraph is of the form: USRP2 Source -- RRC Filter -- Costas Loop -- Mueller and Muller Synch -- Complex to Real -- Binary Slicer -- Descrambler -- File Sink. The transmitter flowgraph uses the same blocks as per digital-bert/transmit_path.py, but with a USRP2 sink. I am transmitting over-the-air, and clocks are not synchronised between Tx and Rx. I have a gigabit Ethernet link, and 2 x 2 GHz CPUs in my PC, which is running Ubuntu 9.10. Can anyone suggest why I am getting so many over-runs, and how I could get around this problem? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] IQ imbalance...
Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Not sure if this got through the first time, as I never received it
myself. Apologies if this is a double post.
-Original Message-
From: Ian Holland
Sent: Wednesday, 7 April 2010 1:51 PM
To: discuss-gnuradio@gnu.org
Subject: Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the referenced paper, where mm_error
corresponds to mu(k) in eqn. (8). However, if I have interpreted this
correctly, what is implemented is actually:
\mu(k) = Real{[p(k) - p(k-2)] \times \hat{c}^{*}(k-1) - [\hat{c}(k) -
\hat{c}(k-2)] \times p^{*}(k-1)},
whereas eqn. (8) in the referenced omMM paper, is actually:
\mu(k) = Real{[\hat{c}(k) - \hat{c}(k-2)] \times p^{*}(k-1) +
\hat{c}^{*}(k-1) \times [p(k) - p(k-2)]}
Have I missed something here? Are these lines of code not meant to
implement eqn (8) as I suspected?
Thanks
Ian.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the referenced paper, where mm_error
corresponds to mu(k) in eqn. (8). However, if I have interpreted this
correctly, what is implemented is actually:
\mu(k) = Real{[p(k) - p(k-2)] \times \hat{c}^{*}(k-1) - [\hat{c}(k) -
\hat{c}(k-2)] \times p^{*}(k-1)},
whereas eqn. (8) in the referenced omMM paper, is actually:
\mu(k) = Real{[\hat{c}(k) - \hat{c}(k-2)] \times p^{*}(k-1) +
\hat{c}^{*}(k-1) \times [p(k) - p(k-2)]}
Have I missed something here? Are these lines of code not meant to
implement eqn (8) as I suspected?
Thanks
Ian.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] running OFDM on USRP2
I have been inactive on this for some time due to other issues with my USRP2s. However, I have been able to look into this again now, with Veljko's modified code. I run as root, and also had the realtime scheduling enabled, however on the receive side I see nothing until the transmitter stops transmitting, at which time I see timeout. This seems to be the same problem that Bin had (except without the realtime scheduling issue). Bin, did you end up resolving this issue? Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Tom Rondeau Sent: Thursday, 4 February 2010 11:56 PM To: bin zan Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote: Hi Tom, In our case, even with script from Veljko, the OFDM receiver doesn't show any thing. And we always see usrp2: failed to enable realtime scheduling. Do you think that will cause problem? Thanks, Bin No, that message is just telling you that you don't have permissions to run it at the highest priority. It means you won't be able to run as fast, but that shouldn't be the cause of your problems. Tom ___ 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] Receiver sensitivity/noise floor...
Hi All Does anybody have information on what the receiver sensitivity or noise floor is for the XCVR2450 boards with a USRP2. I need to know at what level a spurious signal from another source could cause noticeable interference to a desired signal. Regards Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt Apologies is you got a similar reply about 10 minutes ago, but the webmail logged me out whilst I was trying to send it and it didn't appear in my sent items when I logged back in. You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9 to 5.9 GHz. When we test XCVRs before shipping, we make sure that they will lock from 2.35 to 2.55 and 4.85 to 5.95 so that there is 50 MHz of margin in case of variation due to temperature or other factors. But there is no reason to think that they would lock all the way to the edges of the ranges you list since those are well outside of what we (and the chip manufacturer) specify. Thanks. I had thought the low and high limits in the source code were the spec'd ones. Based on your above comment, combinations A, C, and D would seem to be within spec, though I didn't try all the stepped frequencies for case C or D, but just a few (e.g. 2.4G, 2.462G, 5G). Combination ID | USRP2 Serial | XCVR2450 Serial | Working A | 933 | 990 | YES B | 933 | 988 | NO C | 1159 | 990 | YES D | 1159 | 988 | YES In my testing today, an additional problem was also noticed, as below. To simplify testing, you only need to run either RX or TX since they both share the same synthesizer on the XCVR2450. Thanks. I will do this in future. Normally I would tell you to send the parts back for me to check them, but since you are in AU, it would be expensive and take a long time. Instead, we may be able to debug this if you have an oscilloscope. If so, can you look at the signal on R45 and R56 on the XCVR? Note the frequency, and high and low voltages for each of the 4 combinations you mention above. They should look like a square wave in all cases. We have a borrowed oscilloscope spec'd to 1.5 GHz with no probe. I will try to borrow or buy a suitable probe. Can you confirm R45 and R56 are just digital logic signals, as would seem to be the case from what you state above? Assuming the signal you were transmitting was a sine wave with a baseband frequency of 0, then what you are seeing here is completely expected and normal. When the clocks are not locked to the same reference, there is some frequency error, and the signal received is at some frequency other than exactly on the LO of the receiver, and it will get through just fine. However, when the 2 clocks are locked to the same reference, the transmitted tone will be received exactly on the LO frequency of the receiver. When this is downconverted to baseband, it will appear at DC, and it will be nulled out by the DC offset correction, which occurs in both the analog and digital domains. You can turn off the digital one, but not the analog one on the XCVR. To demonstrate this, you can run the following commands: - To show a good tone being received: usrp_siggen.py -f 5.65G -A 0.1 -x 100k --sine usrp2_fft.py -f 5.65G - To show the tone being nulled out: usrp_siggen.py -f 5.65G -A 0.1 -x 0 --sine usrp2_fft.py -f 5.65G Whoops. Didn't think about the DC offset correction. It was a sine wave at the carrier frequency that I tried. I will hence try your suggestion tomorrow, as it is evening here and I am at home without access to the radios. Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt I have completed the probing as you suggested. The results are in the following table. Please note that the voltages did not seem to be stable when I tried reprobing in some cases. An example of this is for R45, where I give two sets of results for Combo D. Also, please note the following expanded definitions for comments in the table. Triangle = The wave looked more like a triangular wave, never really settling on a fixed high or low level. Square50 = The wave looked approximately square, with equal time in low/high states. Square33 = The wave looked approximately square, with approx. 1/3 time in the high state, and 2/3 time in the low state. Results for probing R45: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -12.8 | 100 | Triangle B | 933 | 988 | NO| 19.6| -16 | 100.184 | Triangle C | 1159 | 990 | YES | 20.8| -19.2 | 100 | Triangle D(1st)| 1159 | 988 | YES | 21.2| -20 | 100.125 | Triangle D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)| Triangle Results for probing R56: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -7.6 | 33.3| Square33 B | 933 | 988 | NO| 15.2| -6| 33.3| Square33 C | 1159 | 990 | YES | 15.2| -6.8 | 33.3| Square33 D | 1159 | 988 | YES | 12 | -11.6 | 49.969 | Square50 I guess, the difference in the R56 for case D (the only case for which XCVR 988 was able to set the frequency) may shed some light??? Anyway, hopefully from these results you will be able to determine which card is suspected to have the problem. Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt Additional to below: I tried to resume normal testing with A as Rx and D as Tx. Now, it seems I have an offset of about 2 MHz using internal clocks and running usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am unable to tune D for the low (2.4 GHz) band anymore. In fact, when I just tried again I don't even seem to be able to detect any received signal even in the high band, and even though it appears to lock on D. Regards Ian. Hi Matt I have completed the probing as you suggested. The results are in the following table. Please note that the voltages did not seem to be stable when I tried reprobing in some cases. An example of this is for R45, where I give two sets of results for Combo D. Also, please note the following expanded definitions for comments in the table. Triangle = The wave looked more like a triangular wave, never really settling on a fixed high or low level. Square50 = The wave looked approximately square, with equal time in low/high states. Square33 = The wave looked approximately square, with approx. 1/3 time in the high state, and 2/3 time in the low state. Results for probing R45: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -12.8 | 100 | Triangle B | 933 | 988 | NO| 19.6| -16 | 100.184 | Triangle C | 1159 | 990 | YES | 20.8| -19.2 | 100 | Triangle D(1st)| 1159 | 988 | YES | 21.2| -20 | 100.125 | Triangle D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)| Triangle Results for probing R56: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -7.6 | 33.3| Square33 B | 933 | 988 | NO| 15.2| -6| 33.3| Square33 C | 1159 | 990 | YES | 15.2| -6.8 | 33.3| Square33 D | 1159 | 988 | YES | 12 | -11.6 | 49.969 | Square50 I guess, the difference in the R56 for case D (the only case for which XCVR 988 was able to set the frequency) may shed some light??? Anyway, hopefully from these results you will be able to determine which card is suspected to have the problem. Thanks Ian. ___ 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
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt Additional to below: I tried to resume normal testing with A as Rx and D as Tx. Now, it seems I have an offset of about 2 MHz using internal clocks and running usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am unable to tune D for the low (2.4 GHz) band anymore. In fact, when I just tried again I don't even seem to be able to detect any received signal even in the high band, and even though it appears to lock on D. Regards Ian. Hi Matt I have completed the probing as you suggested. The results are in the following table. Please note that the voltages did not seem to be stable when I tried reprobing in some cases. An example of this is for R45, where I give two sets of results for Combo D. Also, please note the following expanded definitions for comments in the table. Triangle = The wave looked more like a triangular wave, never really settling on a fixed high or low level. Square50 = The wave looked approximately square, with equal time in low/high states. Square33 = The wave looked approximately square, with approx. 1/3 time in the high state, and 2/3 time in the low state. Results for probing R45: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -12.8 | 100 | Triangle B | 933 | 988 | NO| 19.6| -16 | 100.184 | Triangle C | 1159 | 990 | YES | 20.8| -19.2 | 100 | Triangle D(1st)| 1159 | 988 | YES | 21.2| -20 | 100.125 | Triangle D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)| Triangle Results for probing R56: Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) | Comment --- A | 933 | 990 | YES | 16 | -7.6 | 33.3| Square33 B | 933 | 988 | NO| 15.2| -6| 33.3| Square33 C | 1159 | 990 | YES | 15.2| -6.8 | 33.3| Square33 D | 1159 | 988 | YES | 12 | -11.6 | 49.969 | Square50 I guess, the difference in the R56 for case D (the only case for which XCVR 988 was able to set the frequency) may shed some light??? Anyway, hopefully from these results you will be able to determine which card is suspected to have the problem. Thanks Ian. ___ 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
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Josh I am now in a position to summarise what I have observed. - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Do you have any idea what might be wrong? Has such behaviour ever been previously observed? Also, can you please comment as to whether it is likely that the other XCVR2450 will keep working with at least one USRP2? Cheers Ian. Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedly failed this morning, is now working with the other USRP2, though still unable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whether somehow one XCVR2450 has an affinity for one particular USRP2, and won't work on the other, but I can't really understand why that should be the case. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signal from one USRP2's antenna and display the correct spectrum on the receiving USRP2. Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ 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
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt Are you able to also comment on the problem that I am having? (Summary below): - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Recall: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Ian Holland would like to recall the message, [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt Sorry I wasn't completely clear in my previous post below. Specific details are as follows: When I say it fails to lock over the full high band and low band, what I mean is as follows. I ran a test program to step through the frequencies 2.3 GHz to 2.6 GHz, and 4.8 to 6.1 GHz in 10 MHz increments, and for every single one of those frequencies, it failed to tune the Rx frequency and it also failed to tune the Tx frequency. This was, based on earlier debugging, shown to be due to it not locking (i.e. Lock detect bit was not set). Serial number combinations are as follows. Please note that by Working, I mean not all frequencies fail to tune. However, some frequencies near the edges of the lower band, and the upper edge of the higher band, intermittently fail to tune even for combinations of cards I refer to in the table as Working. Combination ID | USRP2 Serial | XCVR2450 Serial | Working A | 933 | 990 | YES B | 933 | 988 | NO C | 1159 | 990 | YES D | 1159 | 988 | YES In my testing today, an additional problem was also noticed, as below. Whilst using the internal clocks, a test was run to compare sampling rates using combination A as Rx and combination D as Tx. As would be expected without locked clocks, the sampling rates at Tx and Rx differed. Then, another test was performed using the same external 10 MHz reference to both Tx and Rx USRP2s. As soon as the external reference signal was fed into the reference clock input of combination D (Tx), the transmitted signal level was observed to drop into the noise floor, hence, I was unable to reliably detect the transmitted signal with locked clocks. (I had previously run the same test with the BasicTx and BasicRx daughterboards, connected by and SMA-SMA cable, and this effect had not occurred with the BasicTx/BasicRx. Instead, the sampling rates at Tx and Rx were identical, and I was able to successfully demodulate a file transmitted using BPSK). Best Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Thursday, 4 February 2010 4:24 PM To: Ian Holland Cc: j...@ettus.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2 Ian, When you said it fails to lock over the full high band and low band do you mean it locks nowhere, or do you mean that it locks on some frequencies, but not everywhere? If the latter, can you be more specific about where it locks and where it doesn't? Also, what are the serial numbers of your USRP2s and your XCVRs? Which are the working combos and which combos fail? Thanks, Matt On 02/03/2010 04:56 PM, Ian Holland wrote: Hi Josh I am now in a position to summarise what I have observed. - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Do you have any idea what might be wrong? Has such behaviour ever been previously observed? Also, can you please comment as to whether it is likely that the other XCVR2450 will keep working with at least one USRP2? Cheers Ian. Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedlyfailed this morning, is now working with the other USRP2, though stillunable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whethersomehow one XCVR2450 has an affinity for one particular USRP2, and won'twork on the other, but I can't really understand why that should be thecase. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signalfrom one USRP2's antenna and display the correct spectrum on the receivingUSRP2. Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware
RE: [Discuss-gnuradio] running OFDM on USRP2
Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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
RE: [Discuss-gnuradio] running OFDM on USRP2
Thanks Veljko Actually, the problems I had were not with the OFDM case, but just benchmark_tx.py and benchmark_rx.py. Are similar modifications necessary for those scripts? Ian. Hi, The example provided with the gnuradio codebase requires small modifications in order to work with USRP2. You can try with the modifications I made: www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz In my case with XCVR2450 daughter boards running the following works fine: transmitter: benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 receiver: benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128 You can try with the transmitter only first and usrp2_fft.py on the other end, just to see if there's something getting transmitted and if it looks like OFDM. cheers, veljko 2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au: Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Manav I tried both of my daughterboards with the same SD card in the USRP2, so perhaps we were actually facing different problems, or at least I am facing an additional problem with one of my cards. Your problem may be resolved once you try Josh's earlier suggestion of reflashing the latest FPGA and firmware images, but of course you will need an SD card reader to do this. You should be able to find them at any electronics/photography/home entertainment store, and they are quite cheap. Ian. From: Manav Seth [mailto:smartyma...@gmail.com] Sent: Wednesday, 3 February 2010 10:54 AM To: Ian Holland Cc: j...@ettus.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2 Hi, The problem I guess is with the SD cards only. Even I was facing the same problem. But today I tried with an old SD card and it worked. I am not able to catch hold of a card reader and the one in my laptop is not working. manav On Tue, Feb 2, 2010 at 5:14 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/ http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ %0Alib/ db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Perhaps? We only have two USRP2s and 2 XCVR2450s. However, if it was the SD card, I would think both XCVR2450s should have the problem. Actually, even the better of the two occasionally fails, so I can't be sure. Ya, what I mean is that for you too the problem may be the SD card only. Actually we had got around 20 USRP's/daughterboards from Ettus and none of them were working with the SD cards they supplied with them (20 in all). When I tried with an older SD card, it worked. On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedly failed this morning, is now working with the other USRP2, though still unable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whether somehow one XCVR2450 has an affinity for one particular USRP2, and won't work on the other, but I can't really understand why that should be the case. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signal from one USRP2's antenna and display the correct spectrum on the receiving USRP2. Best Regards Ian. Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ 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
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Manav
I haven't really fixed it, but rather get a different error. To do this,
I updated to the latest copy of firmware and fpga images as Josh had
suggested.
I am yet to try the debug port and see if it is failing to lock.
Hopefully I can try this today.
Ian.
From: Manav Seth [mailto:smartyma...@gmail.com]
Sent: Friday, 29 January 2010 6:11 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
Hey Ian,
How did the problem get fixed? I mean what frequency you are setting
with the -f option?
Regards,
Manav
On Thu, Jan 28, 2010 at 10:17 PM, Ian Holland
ian.holl...@rlmgroup.com.au wrote:
Thanks Josh
This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says channel 0 not receiving. However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can't be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?
Regards
Ian.
USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(...etc...)
Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/
and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ
-Josh
On 01/28/2010 06:14 PM, Ian Holland wrote:
Hi Matt
I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:
usrp2: channel 0 not receiving
usrp2::rx_sample() failed
I only recently received my USRP2s and XCVR2450s, which were shipped
at
the end of December. Are there any known issues with the firmware on
the
SD cards at this time, or do you have any other idea why I can't seem
to
tune frequencies on these cards?
Thanks
Ian.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Sent: Friday, 29 January 2010 12:35 PM
To: Manav Seth
Cc: Ian Holland; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
USRP2
The -f argument to usrp2_fft.py is the frequency. By putting -f
1000
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
of that range. I would suggest you try something like:
usrp2_fft.py -f 5.7G
Matt
On 01/28/2010 05:35 PM, Manav Seth wrote:
Actually no...its always returning false...
when I use usrp2_fft.py with -f 1000 then output does come but still
it
is unable to set the initial frequency though it did receive.
I am still trying to figure out the problem...
On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
ian.holl...@rlmgroup.com.aumailto:ian.holl...@rlmgroup.com.au
wrote:
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
ian.holl...@rlmgroup.com.aumailto:ian.holl...@rlmgroup.com.au
wrote:
Hi All
I have been trying to set the Tx and Rx frequencies when using
an
XCVR2450 with a USRP2, but it seems these keep failing. A
snippet
of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and
the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying
nothing is
received on channel 0.
Does anyone know what the problem could be?
Thanks
Ian.
/* try tuning Tx to a test frequency */
double Fc = 24.0;
usrp2::tune_result TxTuneResult;
bool successTx = device-set_tx_center_freq(Fc,
TxTuneResult);
if(successTx) {
cout Tx Tune
Successful:\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
else {
cout Failed to tune Tx.\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
ian.holl...@rlmgroup.com.au wrote:
Hi All
I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying nothing is
received on channel 0.
Does anyone know what the problem could be?
Thanks
Ian.
/* try tuning Tx to a test frequency */
double Fc = 24.0;
usrp2::tune_result TxTuneResult;
bool successTx = device-set_tx_center_freq(Fc,
TxTuneResult);
if(successTx) {
cout Tx Tune Successful:\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
else {
cout Failed to tune Tx.\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
cout \n;
___
From: Manav Seth [mailto:smartyma...@gmail.com]
Sent: Thursday, 28 January 2010 3:29 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on USRP2
Ya, its failing for me too...set_tx_center_freq is always failing
(though I am writing my code in python)..
not able to find the cause...
Have you been able to get any of the pre-written scripts (e.g.
usrp2_fft.py or usrp_siggen.py) working? I can't even get those to work.
I tried usrp_siggen.py in verbose this morning and noticed again it was
unable to set the Tx frequency. Also, I think the error I had mentioned
above re usrp2_fft.py would be because the rx frequency couldn't be set.
I have tried two of the daughtercards on one USRP2, and one of those two
cards on the other USRP2, and still can't get it to set, though it
worked fine using the same code for the BasicTx and BasicRx.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Matt
I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:
usrp2: channel 0 not receiving
usrp2::rx_sample() failed
I only recently received my USRP2s and XCVR2450s, which were shipped at
the end of December. Are there any known issues with the firmware on the
SD cards at this time, or do you have any other idea why I can't seem to
tune frequencies on these cards?
Thanks
Ian.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Sent: Friday, 29 January 2010 12:35 PM
To: Manav Seth
Cc: Ian Holland; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
The -f argument to usrp2_fft.py is the frequency. By putting -f 1000
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY outside
of that range. I would suggest you try something like:
usrp2_fft.py -f 5.7G
Matt
On 01/28/2010 05:35 PM, Manav Seth wrote:
Actually no...its always returning false...
when I use usrp2_fft.py with -f 1000 then output does come but still
it
is unable to set the initial frequency though it did receive.
I am still trying to figure out the problem...
On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
ian.holl...@rlmgroup.com.au mailto:ian.holl...@rlmgroup.com.au
wrote:
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
ian.holl...@rlmgroup.com.au mailto:ian.holl...@rlmgroup.com.au
wrote:
Hi All
I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet
of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying
nothing is
received on channel 0.
Does anyone know what the problem could be?
Thanks
Ian.
/* try tuning Tx to a test frequency */
double Fc = 24.0;
usrp2::tune_result TxTuneResult;
bool successTx = device-set_tx_center_freq(Fc,
TxTuneResult);
if(successTx) {
cout Tx Tune Successful:\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
else {
cout Failed to tune Tx.\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
cout \n;
___
From: Manav Seth [mailto:smartyma...@gmail.com
mailto:smartyma...@gmail.com]
Sent: Thursday, 28 January 2010 3:29 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
XCVR2450
on USRP2
Ya, its failing for me too...set_tx_center_freq is always
failing
(though I am writing my code in python)..
not able to find the cause...
Have you been able to get any of the pre-written scripts (e.g.
usrp2_fft.py or usrp_siggen.py) working? I can't even get those to
work.
I tried usrp_siggen.py in verbose this morning and noticed again
it was
unable to set the Tx frequency. Also, I think the error I had
mentioned
above re usrp2_fft.py would be because the rx frequency couldn't
be set.
I have tried two of the daughtercards on one USRP2, and one of
those two
cards on the other USRP2, and still can't get it to set, though it
worked fine using the same code for the BasicTx and BasicRx.
___
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
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Thanks Josh
This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says channel 0 not receiving. However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can't be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?
Regards
Ian.
USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(...etc...)
Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/
and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ
-Josh
On 01/28/2010 06:14 PM, Ian Holland wrote:
Hi Matt
I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:
usrp2: channel 0 not receiving
usrp2::rx_sample() failed
I only recently received my USRP2s and XCVR2450s, which were shipped
at
the end of December. Are there any known issues with the firmware on
the
SD cards at this time, or do you have any other idea why I can't seem
to
tune frequencies on these cards?
Thanks
Ian.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Sent: Friday, 29 January 2010 12:35 PM
To: Manav Seth
Cc: Ian Holland; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
USRP2
The -f argument to usrp2_fft.py is the frequency. By putting -f
1000
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
of that range. I would suggest you try something like:
usrp2_fft.py -f 5.7G
Matt
On 01/28/2010 05:35 PM, Manav Seth wrote:
Actually no...its always returning false...
when I use usrp2_fft.py with -f 1000 then output does come but still
it
is unable to set the initial frequency though it did receive.
I am still trying to figure out the problem...
On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
ian.holl...@rlmgroup.com.aumailto:ian.holl...@rlmgroup.com.au
wrote:
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
ian.holl...@rlmgroup.com.aumailto:ian.holl...@rlmgroup.com.au
wrote:
Hi All
I have been trying to set the Tx and Rx frequencies when using
an
XCVR2450 with a USRP2, but it seems these keep failing. A
snippet
of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and
the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying
nothing is
received on channel 0.
Does anyone know what the problem could be?
Thanks
Ian.
/* try tuning Tx to a test frequency */
double Fc = 24.0;
usrp2::tune_result TxTuneResult;
bool successTx = device-set_tx_center_freq(Fc,
TxTuneResult);
if(successTx) {
cout Tx Tune
Successful:\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
else {
cout Failed to tune Tx.\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
cout \n;
___
From: Manav Seth [mailto:smartyma...@gmail.com
mailto:smartyma...@gmail.com]
Sent: Thursday, 28 January 2010 3:29 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
XCVR2450
onUSRP2
Ya, its failing for me too...set_tx_center_freq is always
failing
(though Iam writing my code in python)..
not able to find the cause...
Have you been able to get any of the pre-written scripts (e.g.
usrp2_fft.py or usrp_siggen.py) working? I can't even get those
to
work
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi All
I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying nothing is
received on channel 0.
Does anyone know what the problem could be?
Thanks
Ian.
/* try tuning Tx to a test frequency */
double Fc = 24.0;
usrp2::tune_result TxTuneResult;
bool successTx = device-set_tx_center_freq(Fc,
TxTuneResult);
if(successTx) {
cout Tx Tune Successful:\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
else {
cout Failed to tune Tx.\n;
cout Baseband Frequency:
TxTuneResult.baseband_freq \n;
cout DxC Frequency:
TxTuneResult.dxc_freq \n;
cout Residual Frequency:
TxTuneResult.residual_freq \n;
cout Spectrum Inverted:
(TxTuneResult.spectrum_inverted ? true : false) \n;
}
cout \n;
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
