I’ve discovered that after I turn on the USRP and start receiving there
is
some noise which because of some strange
reason disappear when I start the transmitting part of the board. For
frequencies around 150MHz with the WBX-board
and USRP1, the noise floor is reduced by 5dB, and seriously improves
reception. To make sure that I receive well, I
made myself a simple script like this:
#!/usr/bin/
from gnuradio import usrp
u= usrp.sink_c
Sorry, it was accidentally posted before I was finished writing…
…To make sure that I receive well, I
made myself a simple script like this:
#!/usr/bin/
from gnuradio import usrp
u= usrp.sink_c()
and run that after I’ve started the board.
Does anyone have any suggestion for what might be the cause of this
strange
behavior?
What happens when the usrp sink is initialized that would cause the
receive
noise floor to fall?
Regards, Ruben
2011/5/5 Ruben U. [email protected]
Does anyone have any suggestion for what might be the cause of this
strange behavior?
What happens when the usrp sink is initialized that would cause the
receive noise floor to fall?Regards, Ruben
YOu haven’t said which daughtercard you’re using.
My guess is that you’re using the WBX. In which case, during TX, the
RX chain has one fewer layers
of switch between the LNA and the antenna port (RX2), which will
improve the noise floor a bit.
What is your antenna configuration?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Additional information comes here:
- The same thing is happening for both the inputs, RX2 and TX/RX, on the
WBX-board. - I am using the traditional gnuradio-drivers.
- Even though it’s working well when I just run this little script every
time I start
the USRP, I feel that it’s a bad ad-hoc solution to a problem that I
would
like
to understand.
Ruben
2011/5/5 Ruben U. [email protected]
Hey, thanks
You are right. I’m using the WBX-board. I wrote it in the first post,
but I
understand that
you didn’t see it because of the mess with my split-up posting.
Anyway, I am using a simple indoor antenna, and I get the same result
with a
2m whip as
a log-periodic antenna (which btw. doesn’t have a the correct bandwidth
400MHz+).
Would what you suppose be the case even when the usrp_tx part is only
initialized and not used at
all? (like I do with the simple script)
What is strange is that the noise remains low for as long as the USRP is
running after
I’ve run a script with the usrp.sink_c() and the script has finished. I
hope
there will be
another way of getting rid of the noise inside the receiving script, so
that
I don’t have to
add the usrp.sink_c() in all scripts where I’m not going to do any
transmitting!
Ruben
2011/5/5 Marcus D. Leech [email protected]
Ruben
Is the noise-dip frequency sensitive?
How entrenched are you in “classic” USRP drivers? I strongly encourage
people to move to UHD
unless they have a lot of “classic” code.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Hello, thanks
Yes, the noise-dip is frequency sensitive. I have not been able to fully
characterize it because at
some frequencies it’s bad and at others it’s quite good, and there is
not
really a understandable pattern.
At VHF-frequencies, it’s at least quite bad before I run the script.
I tried installing the latest git version of gnuradio to test if that
would
help - it did not.
Afterwards I tried installing the UHD-drivers, and porting my scripts to
use
them. I am not that deep
entrenched in classic drivers, even though I have been satisfied with
them
until now!! Apparently,
using the UHD-drivers seems to solve the problem!!! Now it’s working
nicely
at once when the USRP is
powered up. Thank’s a lot! What’s actually the problem with the classic
drivers, is still a mystery to me.
By the way, is it possible with the UHD-drivers to transmit from one
script
while receiving in another script??
I can’t seem to get that working like I did with the “classic” drivers.
Ruben
2011/5/5 Marcus D. Leech [email protected]
Afterwards I tried installing the UHD-drivers, and porting my scripts
to use them. I am not that deep
entrenched in classic drivers, even though I have been satisfied with
them until now!! Apparently,
using the UHD-drivers seems to solve the problem!!! Now it’s working
nicely at once when the USRP is
powered up. Thank’s a lot! What’s actually the problem with the
classic drivers, is still a mystery to me.
My suspicion is that the classic drivers just happen to produce some
kind of localized noise (probably
due to the aeMB in the USRP2), and I would expect such noise to have
spectral peaks. It’s probably
the case that the UHD firmware+fpga has a different spectral
signature. Just a guess.
By the way, is it possible with the UHD-drivers to transmit from one
script while receiving in another script??
I can’t seem to get that working like I did with the “classic” drivers.
Well, with UHD, the communications are over UDP+IP, using a socket
interface, and it’s likely
that can’t be shared among different processes. But, perhaps Josh
will pop up and gives us
a quick discourse on the subject.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium