Hi,
Are there any good (standard) tests for the flex2400, or can anyone tell
me what I’m doing wrong?
I tested the BasicRX and BasicTX boards by plugging a shielded wire
between them, running usrp_oscope.py, and running the
test_usrp_standard_tx script. Signal in, signal out - happiness, after I
matched interpolation rates to eliminate overruns and set up sufficient
sampling frequencies.
I’m trying to test the flex2400 the same way - I stuck a wire from the
TX/RX socket to the RX2 socket, ran usrp_oscope, and ran the standard tx
script. Nothing. I’ve tried different frequencies, playing with the
gain, and all kinds of other things, but I don’t see any change in the
signal.
A second question is: With the basic boards as described earlier, I run
[usrp_fft.py -f 1M -d 32] and then run the signal generator
[usrp_siggen.py -f 1M -i 32]. The spectrum I see has a small peak (but,
at 0db) centered at 0 and then a large peak >50db near +0.1MHz. What is
going on here?
Thanks,
-Dan
I’m trying to test the flex2400 the same way - I stuck a wire from the
TX/RX socket to the RX2 socket, ran usrp_oscope, and ran the standard
tx script. Nothing. I’ve tried different frequencies, playing with the
gain, and all kinds of other things, but I don’t see any change in the
signal.
Don’t do this - you may have fried your receiver. The RFX2400 puts
out 10 mW, or +10 dBm, and IIRC the maximum safe input on the receiver
is 0 dBm (this is pretty normal for receivers that aren’t $20K test
equipment, and for those the max is hardly ever more than +30 dBm).
If you have a single RFX2400, then using the secondary receive socket
is more complicated - I think you have to tell the oscope to listen on
input B. We’ve used these boards at BBN, but I’m not sure we tried
the secondary inputs. There should be enough stray RF from 802.11 for
oscope to show ambient - try 2437 MHz.
Your question about a standard test is a good one, though - it would
be nice if people with procedures put them on the wiki.
–
Greg T. <[email protected]>
On Thu, Nov 09, 2006 at 09:56:37PM -0800, Dan H. wrote:
Hi,
A second question is: With the basic boards as described earlier, I
run [usrp_fft.py -f 1M -d 32] and then run the signal generator
[usrp_siggen.py -f 1M -i 32]. The spectrum I see has a small peak
(but, at 0db) centered at 0 and then a large peak >50db near +0.1MHz.
What is going on here?
Try usrp_siggen.py --help
You specified the RF center frequency, but took the default for the
signal generated at baseband (the -w ). By default it’s 100kHz,
thus the peak near +0.1 MHz.
Admittedly this is a somewhat unusual interface for somebody who may
just want a sine wave out. On the other hand, this code originally
existed to allow us to confirm that the system was working the way we
expected it behind the scenes.
I just checked in an update to usrp_siggen.py that now has the --help
list the default values for additional properties.
Eric
It’s beginning to look like future daughterboards should include an
attenuator or fuse or something. This would avoid the idiotic result
that you plug ‘transmit’ into ‘receive’, as any sane computer-oriented
person would do, and (invisibly) fry your board.
Having the same connector on the tx and rx ports makes it that much
more likely to happen. (I’m not arguing that we should enter
connector hell by making them different!)
Prominently selling a “loopback cable” that includes an appropriate
attenuator would also be a positive step. Perhaps each amplified
transmiter should come with one, in a nice ethernet-orange color.
John