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
Ian- 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. If you rule out the SD card, then is there a way you and Manav can compare PCB revisions for USRP2 and XCVR2450 -- and USRP2 logic revision -- and make sure your systems are absolutely identical? Even a small rework or logic change might make a difference... -Jeff 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 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
Manav, Sorry for not being active in this thread. Things have been very busy here. In any case, it sounds like you are seeing something very different from Ian. You are having one of 2 problems -- - You received bad SD cards. If you power up your USRP2 with the SD card in it, and you don't see 2 LEDs light up on the front panel, then this is what you are seeing, and it has nothing to do with the XCVR2450. Go to this page and follow the directions there: http://www.ettus.com/flash - If the card is not bad, then you have a flash version which does not match your GNU Radio install. Newer flash cards come with new versions of the firmware and FPGA, but these will only work with updated GNU Radio code. If this is the case, you either need to update GNU Radio, or put an old version of the FPGA and firmware on your card. I recommend the first option. Matt On 02/02/2010 05:08 PM, Manav Seth wrote: 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 mailto:ian.holl...@rlmgroup.com.au wrote: 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 mailto:smartyma...@gmail.com] *Sent:* Wednesday, 3 February 2010 10:54 AM *To:* Ian Holland *Cc:* j...@ettus.com mailto:j...@ettus.com; discuss-gnuradio@gnu.org mailto: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 mailto: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
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 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 ___ 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] Unable to tune Tx or Rx with XCVR2450 on USRP2
On 02/03/2010 10:19 PM, Ian Holland wrote: 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). Clearly locking nowhere is a problem. 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. 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. 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. 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. 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). 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 Matt ___ 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, Ya, I am having the second problem. But, I have the gnuradio 3.2.2 code base only. Will try to checkout again from the git repository and build. Anyways, I did have a working card. So if this does not work, I will try to copy this card to all the other cards. Can you please guide me how to copy a SD hard having a working image to another using a card reader. Today I tried doing this but the card was not being recognised. Thanks, Manav On Wed, Feb 3, 2010 at 10:26 PM, Matt Ettus m...@ettus.com wrote: Manav, Sorry for not being active in this thread. Things have been very busy here. In any case, it sounds like you are seeing something very different from Ian. You are having one of 2 problems -- - You received bad SD cards. If you power up your USRP2 with the SD card in it, and you don't see 2 LEDs light up on the front panel, then this is what you are seeing, and it has nothing to do with the XCVR2450. Go to this page and follow the directions there: http://www.ettus.com/flash - If the card is not bad, then you have a flash version which does not match your GNU Radio install. Newer flash cards come with new versions of the firmware and FPGA, but these will only work with updated GNU Radio code. If this is the case, you either need to update GNU Radio, or put an old version of the FPGA and firmware on your card. I recommend the first option. Matt On 02/02/2010 05:08 PM, Manav Seth wrote: 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 mailto:ian.holl...@rlmgroup.com.au wrote: 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 mailto:smartyma...@gmail.com] *Sent:* Wednesday, 3 February 2010 10:54 AM *To:* Ian Holland *Cc:* j...@ettus.com mailto:j...@ettus.com; discuss-gnuradio@gnu.org mailto: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 mailto: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
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, 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.auwrote: 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); ___ 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 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
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.auwrote: 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
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
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.auwrote:
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
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
Ya..i know...but if i put a legal value..its saying cannot receive on
channel 0..its strainge..but dont know what is happening...
can somebody please help...
its happening with all the example programs...I have also now modified quite
a few example scripts which are for usrp older version to work with
usrp2..but for them also..its giving the same errors...though they use to
work with the older usrp...
On Thu, Jan 28, 2010 at 7:04 PM, Matt Ettus m...@ettus.com wrote:
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
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
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.
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
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
On 01/28/2010 09:17 PM, Ian Holland 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
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)
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:
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
Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
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
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.auwrote:
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
[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
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...
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland ian.holl...@rlmgroup.com.auwrote:
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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
