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.
Read the mailing list of the GNU project right here! The information here is regarding the GNU radio project for USRP radios.
Wednesday, February 3, 2010
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment