-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
usrp_siggen.py -i 16 -f 2.485G
usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
In the first set of data, the noise level is what I’d expect and
everything works hunky-dory. After the siggen, however, it all goes
haywire, the noise floor becomes huge even though an adjacent USRP sees
nothing. See
http://www.cs.washington.edu/homes/dhalperi/random/pre_and_post.jpg
for graphs of the raw sample amplitudes.
Can anyone duplicate / explain this? Thanks!
- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHlD78y9GYuuMoUJ4RAk3bAJ9AONim3nGAapElcL5odPvyUww7tQCePGCM
3rmw0m3rTsKFgb1TYSb8H6o=
=25GS
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I should add that I’ve duplicated this with multiple USRPs of different
revisions and different revisions of the RFX 2400 (the 12-26-2006
version as well). So I don’t think I broke my hardware… I’ve also
duplicated it at multiple frequencies.
Dan H. wrote:
http://www.cs.washington.edu/homes/dhalperi/random/pre_and_post.jpg
for graphs of the raw sample amplitudes.
Can anyone duplicate / explain this? Thanks!
-Dan
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHlD/+y9GYuuMoUJ4RAuWXAKCzQocG4GrfjBIkSQtow+s7fTbX2wCeJthO
PiMD8UFR4GQKmST96EjM7TA=
=T8aJ
-----END PGP SIGNATURE-----
Dan H. wrote:
Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
usrp_siggen.py -i 16 -f 2.485G
usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
In the first set of data, the noise level is what I’d expect and
everything works hunky-dory. After the siggen, however, it all goes
haywire, the noise floor becomes huge even though an adjacent USRP sees
nothing.
I wonder if somehow the USRP transmitter is getting left powered up.
The mixer would be getting random noise and upconverting it to your
passband. This would feed through from the blocked side of the TX/RX
switch (about 30dB of attenuation) into the receiver.
You’d have to measure the logic level at the mixer chip enable pin to be
sure.
If this is the case, I have a suspicion about the cause.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Interesting. I don’t have a logic analyzer handy but after the holiday I
may find someone who knows how to use one. More importantly, do you have
suspicions about the solution? 
As another data point, I’ve found that performing the second receive at
different frequencies can bring the noise floor back to normal. If I
transmit at 2.48G and receive at 2.485G the noise floor is normal. With
some other RX frequencies, (I think 2.445G) the same problem persists.
Johnathan C. wrote:
nothing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHlOKoy9GYuuMoUJ4RAumXAKCv+cDlNFgGxorc7Wpwc4LNZ7ApWQCgxarx
SV6hXvvtbb2Bri+0XsHynHU=
=t3l7
-----END PGP SIGNATURE-----
Dan H. wrote:
You’d have to measure the logic level at the mixer chip enable pin to be
sure.
I have a logic analyzer and RFX2400 board handy that I can test this
out. Which pin is the mixer chip enable pin?
On 1/21/08, Dan H. [email protected] wrote:
Interesting. I don’t have a logic analyzer handy but after the holiday I
may find someone who knows how to use one.
I can try to replicate it in my lab.
More importantly, do you have suspicions about the solution?
The daughterboard code, when the daughterboard goes out of scope,
issues the commands to powerdown the transmit and receive mixers. If
for some reason the class destructor doesn’t get called, it would
leave it turned on.
We recently checked in a change to the way Python daughterboard
objects are handled; a bug here might be causing what you are seeing.
Just a hunch, though. (See private email for further.)
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
On 1/21/08, George N. [email protected] wrote:
When running usrp_rx_cfile.py the first time, i get no voltage reading
from this pin.
Then I run usrp_siggen.py and get a little under 1V at the pin on average.
When I stop usrp_siggen.py the pin goes down to about 200mV, which is
where it stays when i run usrp_rx_cfile.py the second time.
This should be a 3.3V logic level. Can you verify you have the right
pin?
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
On 1/21/08, George N. [email protected] wrote:
I have a logic analyzer and RFX2400 board handy that I can test this
out. Which pin is the mixer chip enable pin?
U101, pin 8.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
Johnathan C. wrote:
This should be a 3.3V logic level. Can you verify you have the right pin?
I’ve drawn a red arrow to where I’m measuring from:
http://www.andrew.cmu.edu/user/gnychis/Flex2400.jpg
Johnathan C. wrote:
On 1/21/08, George N. [email protected] wrote:
I have a logic analyzer and RFX2400 board handy that I can test this
out. Which pin is the mixer chip enable pin?
U101, pin 8.
When running usrp_rx_cfile.py the first time, i get no voltage reading
from this pin.
Then I run usrp_siggen.py and get a little under 1V at the pin on
average.
When I stop usrp_siggen.py the pin goes down to about 200mV, which is
where it stays when i run usrp_rx_cfile.py the second time.
On 1/21/08, George N. [email protected] wrote:
This should be a 3.3V logic level. Can you verify you have the right pin?
I’ve drawn a red arrow to where I’m measuring from:
http://www.andrew.cmu.edu/user/gnychis/Flex2400.jpg
This is the right pin. Are you using a high-impedance probe?
On another note, Dan verified that the problem I though it might
be–wasn’t.
I’ll measure this in a moment and see what I come up with.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
On 1/20/08, Dan H. [email protected] wrote:
In the first set of data, the noise level is what I’d expect and
everything works hunky-dory. After the siggen, however, it all goes
haywire, the noise floor becomes huge even though an adjacent USRP sees
nothing. See
http://www.cs.washington.edu/homes/dhalperi/random/pre_and_post.jpg
for graphs of the raw sample amplitudes.
This has been fixed in r7486 on the trunk, and will eventually show up
in GNU Radio 3.1.2. A bug was found that left some of the transmitter
circuitry enabled during receive.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
