I am currently using two USRP N210 rev4 with a RFX2400 daughter board
and a
VERT2450 antenna on each. I am having trouble transmitting a signal
between
the two USRPs even though they are right next to each other.
On the transmitting flowgraph, I have a signal source sending a square
wave
at 1kHz with an amplitude of 100m connected to a USRP sink. On the
receiving flowgraph, I have a USRP source multiplied with a complex
cosine
to shift the signal to baseband. Then I use a lowpass filter before
sending
to a scope sink or fft sink.
Whenever I use the scope sink to look at the incoming signal, it looks
nothing like the square wave I am sending. It sometimes looks like a
sine
wave with a frequency other than 1kHz, or it looks something like the
picture titled received_signal.png ( I only showed one of the lines
because
it was too cluttered with both of them ). When I send a cosine or a
constant signal, I receive a sine on the scope, but the amplitude jumps
a
little and the frequency jumps up and down one or two kHz.
I also wanted to know what happens to the signal in the RFX2400
daughterboard and what the FPGA does to the signal. I think I read
somewhere that the FPGA converts the signal to baseband, but I was not
sure
if that is true. I have attached the flowgraphs used for transmitting
and
receiving.
to a scope sink or fft sink.
daughterboard and what the FPGA does to the signal. I think I read
somewhere that the FPGA converts the signal to baseband, but I was not sure
if that is true. I have attached the flowgraphs used for transmitting and
receiving.
Perhaps you are seeing a small frequency offset between RX and TX. I
recommend experimenting a little more in simulation:
What happens you pass the same square wave through that low pass
filter you mentioned. Whats it look like?
What happens when you apply a small frequency shift to the square
wave? I recommend using the channel model block for this.
Perhaps you are seeing a small frequency offset between RX and TX. I
recommend experimenting a little more in simulation:
What happens you pass the same square wave through that low pass
filter you mentioned. Whats it look like?
When I pass the square wave through the low pass filter it does become
a
sine wave, so that means it’s normal. Does the low pass filter implement
a
Fourier transform? If it does, that could explain why if ends up looking
like a sine. In the comments in the fr_firdes.cc file, it says “// a
little
algebra gets this into the more familiar sin(x)/x form”. This looks like
the Fourier transform of the rect(t) function, but I can’t really tell
what
is happening from the code.
What happens when you apply a small frequency shift to the square
wave? I recommend using the channel model block for this.
It took a while to figure what the channel block was used for because I
never seen it while looking through the blocks in grc. The taps
parameter
was used for a filter it seems, but I don’t really understand the taps
very
well. I left it at the default 1.0 + 1.0j hope that is ok for this
purpose.
When I changed the frequency shift parameter in the channel model block,
the signal on the scope sink became “shaky”. If I increase the shift a
little more, the signal changes to something similar to the picture I
attached in the previous post. I think I get a different signal when I
shift frequencies because the signal hovers around 50u whenever I’m not
near the the source’s frequency. I would like to know what units are
used
in the channel model block’s frequency shift parameter because when I
use
150m the Fourier transform sink shows something like a 30kHz shift. I
also
realized that the low pass filter should be set to have a cutoff
frequency
greater than 1kHz.
If I am observing a fluctuation in the RX and TX frequency offset, then
is
there a way to accommodate for this. Since the offset changes at random
intervals, I don’t see a way to shift in the opposite direction by the
correct amount. Now that I know the low pass filter makes a signal look
like a sine wave, is it possible to revert the signal back to the
original
form?
So I’ve been trying some more simulations, and I found that the DPSK
demod and mod blocks allowed me to maintain the signal. Even if I
applied a small offset to the data through the channel model block,
the signal on the scope stayed the way it should. The flow graph is
shown in the channel_model_w_DPSK.png picture.
When I tried this with the USRPs, the only change I made was replacing
the channel model block with a USRP sink and a source. However, when I
run these two flow graphs, nothing shows up on the fft sink or the
scope sink. Does anyone know why this is?
I figured out why the low pass filter was making the square wave look
like a sine wave. The square was represented by a Fourier series. In
other words, it was made up of many sine waves with different
frequencies. The Fourier Series for a square wave is: 4k/pi(sinx +
1/3sin3x + 1/5sin5x + … ) When I applied the low pass filter with
a cutoff frequency of 1.1kHz to a 1kHz square wave, I was cutting off
the sine waves at the higher frequencies, (3kHz, 5kHz, etc.), so it
only showed the first sine wave in the series. If I set the cutoff
frequency of the low pass filter to 30 - 50 times the signal frequency
then I will get a fairly accurate square wave with some ripples on the
horizontal parts on the graph.
As for the frequency offset, if I use the setup shown in the attached
flow graph ( this time with the taps being 1.0 + 0j ) and set the
frequency offset of the channel model block to 1m or less it looks
like a sine wave is being superimposed onto the square wave. I have
tried to filter out the low frequency sine wave, but that disrupts the
square wave. Is there a way to accommodate for the frequency offset
when transmitting and receiving between the USRPs?
You said you replaced the channel model block with a USRP sink and source?
Are you trying to TX / RX using a loopback? If so, remember to use
attenuators so that you don’t blow out your RX chain.
When I said “replaced the channel model block with a USRP sink and
source”, I meant in two separate flow graphs. In other words, I have
the transmit portion of the graph on one computer and the receive
portion on my laptop, and I am trying to send the signal from one USRP
to another. The transmit flow graph has exactly the same blocks up to
the channel model block, but instead I used a USRP_sink instead of the
channel model.The receive flow graph has the portion from the channel
model onward, except the channel model is replaced with the
USRP_source. Also, the throttle was taken out. Sorry if that wasn’t
clear.
Also, the channel model block cannot simply be replaced with a source and
sink. There is a lot of other stuff going on in there - look into the
documentation for the block, as you will need to make other adjustments so
that your samples come out as you expect.
The channel model block contains a timing offset, and noise adder
which I didn’t use in my simulations. The only things I changed were
the frequency offsets and the multipath variable (from what I found
online, it’s used to change amplitude and phase shift of the signal).
The only difference that I can see between the channel model and using
actual USRPs is that USRPs up converts the signal into IF ( I believe
), converts it to analog, and the daughter board converts it to RF.
Then the reverse happens in the other USRP. When the two USRPs are
transmitting, any of the four things that the channel model does can
happen, but the main ones I’m concerned about is the frequency shift.,
and the DPSK block seemed to have taken care of that ( at least in the
simulation ).
I was using the */gr-uhd/examples/grc/uhd_dpsk_mod.grc and other
similar examples as somewhat of a guide, and I don’t see anything that
looks very different from what I used. What kind of other adjustments
must I make?
On Thu, Jul 26, 2012 at 04:09:31PM -0700, Frederick L. wrote:
and the DPSK block seemed to have taken care of that ( at least in the
simulation ).
I was using the */gr-uhd/examples/grc/uhd_dpsk_mod.grc and other
similar examples as somewhat of a guide, and I don’t see anything that
looks very different from what I used. What kind of other adjustments
must I make?
Frederick,
all kinds of stuff can go wrong.
When you say you see ‘nothing’ on the FFT sink, do you mean you see only
noise, or literally nothing?
Here’s a typical ist of things I do when debugging such a link:
Use a spectral analyzer to see if the transmitter is actually
transmitting (where you want it to)
Connect an FFT sink directly to the UHD source to see if the signal
looks as expected
You’ve got a couple of things that surprise me in your FG:
the packet decoder (I’m not 100% what that does) searches for a bit
string? If so, you have no way to guarantee you’re actually receiving
that specific sequence. If you’re literally rx’ing nothing, perhaps that
doesn’t trigger.
Why do you LPF bits?
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Use a spectral analyzer to see if the transmitter is actually
Hi Martin,
I have done more testing and am looking into the way the packet encoder
and
modulation blocks work.
First off, I was able to fix the issue of not being able to see the
signal
on the scope sink ( I was actually not seeing anything last time. i.e.
completely blank ). The problem being I didn’t put a multiply const
block
with a value of 100m in front of the USRP sink. I think this was needed
to
lower the signal strength so that the receiving daughter board was able
to
process the signal. I don’t remember what the max dB the RFX2400
daughter
board can handle, but from what I saw it seems to be about -50dB. This
was
seen on a FFT sink directly connected to the USRP source.
Second, putting the bits through a low pass filter was an error on my
part.
I had the LPF there from before, and had left it there thinking I needed
to
cut off unwanted frequencies. It turns out that I don’t need one at all.
If
I use the packet decoder and the demodulation block, it reproduces the
original signal. From what I understand so far, the packet encoder adds
transmitting information ( preamble, access code, whitener offset, and
whatever is returned from the whiten function, though I am not sure what
the whitener offset and whiten function is for ), converts it to network
byte order ( big endian ), and applies a CRC before sending this
“packet”
out. The packet encoder doesn’t look like it touches the signal data at
all, which seems kind of odd.
Lastly, is it normal for the scope sink to update so slowly? For
example,
If I change the amplitude or frequency of the transmitting wave, it
takes
about 30 seconds before I see a change in the scope sink on the
receiving
laptop. The FFT sink which is connected to the USRP source directly
updates
in 2-3 seconds. Could the packet decoder and demodulation block slow the
scope by that much? The sample rate of the flow graphs are 200k, so I
was
wondering if this is normal behaviour.
You said you replaced the channel model block with a USRP sink and
source?
Are you trying to TX / RX using a loopback? If so, remember to use
attenuators so that you don’t blow out your RX chain.
Also, the channel model block cannot simply be replaced with a source
and
sink. There is a lot of other stuff going on in there - look into the
documentation for the block, as you will need to make other adjustments
so
that your samples come out as you expect.
Cheers,
Ben
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.