I’ve been trying to work out how to do some things on the transmit
side of gnuradio, and I’ve noticed there’s something of a dearth of
documentation. Most of it amounts to “its just like receive, only
backwards.” That’s probably fine for people with signal processing
background (which may be the majority of this community…), but I
find myself getting confused… by looking at some of the examples, I
get a sense of how to initialize all the components in python, but if
I do anything beyond them, I get unexpected results. For example, I
took siggen_min2.py and modified it so that instead of outputting a
pure sine wave, it output sin(wt)+cos(2wt). This did not put anything
resembling sin(wt)+cos(2wt) on the output of the tx board.
Furthermore, chaging w does not some to alter the waveform at all -
only calling u.set_tx_freq changed the output freqency.
Again, it may be that there’s simple something basic here that most
people know because they’ve worked with this before (in which case,
there’s no need to improve the documentation), but for someone without
specific background (i.e. I’m in math and physics), the documentation
is difficult to follow on the transmit end.
On Fri, 2006-05-05 at 15:45 -0700, Erik T. wrote:
resembling sin(wt)+cos(2wt) on the output of the tx board.
Furthermore, chaging w does not some to alter the waveform at all -
only calling u.set_tx_freq changed the output freqency.
I agree that there is definitely a dearth of documentation, especially
for TX.
The [unstated] purpose of siggen_min2 is to transmit different signals
to TX daughterboard A and TX daughterboard B.
In general, without really changing the firmware, any signal sent to
DB-A will output the I signal on one output and the Q on the other. The
same goes for DB-B.
For what you are trying, I would suggest working with usrp_siggen.py
unless you want to use multiple TX daughterboards.
Matt
Ah - I missed the usrp_siggen.py… at any rate, the situation still
arises that I don’t get anything resembling sin(wt)+cos(2wt)… I
guess the biggest aspects of my confusion come from the interpolation
(specified in the usrp.sink_c constructor) - is that interpolating
between 2 points on the curve that’s input into the sink, or does it
just sample the signal however often the interpolation is and fill in
the rest? And for that matter, I don’t see why the u.set_tx_freq is
controlling the output - shouldn’t the frequency specified for the
input sine wave change something (at least if its around the tx
frequency)?
Again, if there’s some web site that you know of that will explain
this all, I’m fine with figuring it out with a little guidance… I
just am getting somewhat buried in the terminology/conventions for
something that seems it should be fairly simple…
On Fri, 2006-05-05 at 16:48 -0700, Erik T. wrote:
Ah - I missed the usrp_siggen.py… at any rate, the situation still
arises that I don’t get anything resembling sin(wt)+cos(2wt)… I
guess the biggest aspects of my confusion come from the interpolation
(specified in the usrp.sink_c constructor) - is that interpolating
between 2 points on the curve that’s input into the sink, or does it
just sample the signal however often the interpolation is and fill in
the rest? And for that matter, I don’t see why the u.set_tx_freq is
controlling the output - shouldn’t the frequency specified for the
input sine wave change something (at least if its around the tx
frequency)?
The USRP DACs sample at 128 MS/s. You can’t send samples that fast over
USB, so you send them at a lower rate. When they get to the USRP, they
are interpolated to 128 MS/s. If you have an interpolation rate of 16
(the minimum), you need to send 8 MS/S over the bus (16 * 8e6 = 128e6).
In essence, the USRP inserts 15 zeros between every sample you send it,
and then filters it so that the intermediate samples form a smooth
curve.
After interpolation, this signal is still limited to +/- 4 MHz since the
original sample rate is 8 MS/s. The digital upconverter (as controlled
by u.set_tx_freq) then upconverts it to you desired center frequency,
which is in the range of +/- 44 MHz IIRC.
What I think you are running into is that your cos(2wt) is at double the
BASEBAND frequency of sin(wt). Both are then shifted up by the
u.set_freq. If w corresponds to 100 kHz, and 2w corresponds to 200 kHz,
and u.set_freq is equal to 5 MHz then you will get tones at 4.8 MHz
(from cos(2wt)), 4.9 MHz (from sin(wt)), 5.1 MHz (from sin(wt)), and 5.2
MHz, from cos(2wt)).
Matt
documentation. Most of it amounts to "its just like receive, only
For what you are trying, I would suggest working with usrp_siggen.py
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Matt E. [email protected]