Translating the signal from baseband to RF

With these old tutorials, it’s hard to determine what blocks I should or
should not be using. I’ve been messing around with wxpython in my
transmission code in order to visually aid with any problems that might
arise. With Tune(), I’m able to see corresonding differences in the
received
signal strength based on what I set the center frequency to be. However,
the
files that I send are not picked up on the receiving side.

After setting up a GUI with wxpython, I think I can see why these files
are
not sending properly. It seems that no matter what I set the center
frequency to, the window that I’ve attatched the modulator to always
shows
the output centered around 0Hz. I’ve been using
gr.frequency_modulator_fc()
for modulation, but upon looking at the header file, I see that the
output
is a complex signal at baseband. Furthermore, nothing in the modulation
code
leads me to believe that the center frequency I tune to has anything to
do
with the modulation itself. Is there another block I should be using to
translate the signal to the RF?

On Wed, Aug 16, 2006 at 02:37:27PM -0500, Michael F. wrote:

With these old tutorials, it’s hard to determine what blocks I should or
should not be using. I’ve been messing around with wxpython in my
transmission code in order to visually aid with any problems that might
arise. With Tune(), I’m able to see corresonding differences in the received
signal strength based on what I set the center frequency to be. However, the
files that I send are not picked up on the receiving side.

The upconversion from complex baseband to the specified RF frequency
takes place in the USRP (actually a combination of the FPGA, AD9862 and
RF daughterboard).

I suggest you start by hooking up an oscilloscope or spectrum analyzer
to the output of whatever daughterboard you’re using, and take a look at
the RF output with that.

Try usrp_siggen.py with a variety of options to begin to understand
what’s going on.

Eric

Thanks. Just glancing at usrp_siggen.py, things look less abstract than
they
did at the the beginning of the summer. I’ll start playing around with
it
right now. As for the output, is there no other way to catch the final
outpuf than with a sprectrum analyzer or oscilloscope? For example,
could I
possibly directly connect one board to another with an SMA cable and run
an
oscilloscope block at the receiver, if there is such a block?

On Wed, Aug 16, 2006 at 03:34:23PM -0500, Michael F. wrote:

Thanks. Just glancing at usrp_siggen.py, things look less abstract than they
did at the the beginning of the summer. I’ll start playing around with it
right now. As for the output, is there no other way to catch the final
outpuf than with a sprectrum analyzer or oscilloscope? For example, could I
possibly directly connect one board to another with an SMA cable and run an
oscilloscope block at the receiver, if there is such a block?

You could do that, but that introduces the whole RX path into the
equation. Until you understand what’s going on, I suggest a trip to the
lab :wink:

Eric

I’ll be able to borrow a spectrum analyzer next week, I just found out.
In
the meantime, I know you pointed out that fsk_{rx,tx).py are outdated.
My
followup question is - are every one of the individual signal processing
blocks obsolete as well? (simple_correlator, bytes_to_syms, file_source,
etc.)? I know the tuning function in that code shouldn’t be used.

Also(this is assuming that the correlator and framer blocks are okay to
use), do you have any idea as to what might be keeping the correlator
from
picking up any data? When I set the center frequency and bandwidth, the
RSSI
readings change accordingly, but nothing is ever dropped into my
filesink. I
thought I might be undersampling on either the receiver of sender sides.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs