Hi Roee,
On 16.11.2015 22:28, Roee Bar wrote:
Hi Marcus,
You understand correctly. I ran this experiment with
USRP block 'length tag’ field enabled and another time with this
field empty (these correspond to ‘signal_with_tag’ and
‘signal_without_tag’ respectively).
Regarding your questions:
1. I am plotting the real part of the received
signal.
Well, then, no surprise: The digital LO used to mix up your signal
to 12.5MHz continues to run between bursts, so the phase changes.
2. I expect to see a perfect sine wave in both
cases. When I zoom in to ‘signal_without_tag’ I see exactly
that. However, the ‘signal_with_tag’ is not (it is very apparent
in the screenshot that it is not a sine wave). Theoretically I
don’t expect that transmitting in burst mode would affect the
received signal at all, but apparently it distorts it.
No distortion. Your signal simply is not just your real part of the
signal.
Best regards,
Marcus
Thanks again,
Roee
Hi Roe!
Your situation is the following, if I understand
correctly:
1. you're producing a real-valued cosine with a
theoretical frequency of 2kHz and a sampling rate of
12,500kHz, so one period of the cosine is 6250 samples.
2. you're putting that into 10,000 sample bursts, and
transmit these through the USRP, which stops the transmit
streamer after every burst.
So, there's two questions:
1. What are you *exactly* plotting? The real, the
imaginary part, the absolute of the received signal?
2. What were you expecting, and what don't you find? Your
axes are a bit too small to see whether we see any
distortion in the signal.
Best regards,
Marcus
On 14.11.2015 01:05, Roee Bar
wrote:
Yes I am changing the frequency on both.
I have replaced the LFTX and the USRP motherboard with
other boards and I get the same results, so I ruled out
a hardware problem.
It's like when using the length_tag feature on the USRP
block it resets the USRP after every packet.
I have created a simple experiment to reproduce this
behavior. It consists of a simple signal generator, a
tagger and two USRP blocks. When I enable the length tag
in the USRP sink, I get a corrupted signal. When I don't
use the length tag I get a nice signal. I attached a
screen shot of GRC, the corrupted signal and the good
signal.
So maybe burst mode should not be used for packets or
there is a bug in uhd/gnuradio.
Roee
On 11/13/2015 02:38 AM,
Marcus Müller wrote:
Hi Roee,
are you changing the frequency on both the transmitter
and receiver?
Because: mixing anything to a higher frequency is
exactly that, a multiplication with a sinusoid.
Best regards,
Marcus
On 13.11.2015 07:01, Roee
Bar wrote:
Hello,
I am experiencing some weird behaviour with USRP
blocks.
I have a PHY block that generates packets with
"packet_len" tag. This stream is the input to a USRP
sink block (the transmitter). Between packets, my
PHY block does not produce anything, so the USRP
assumes zeros until a new packet arrives with
“packet_len” tag (I guess this is what we call
'burst mode'?). The USRP source (the receiver)
receives the signal from the USRP sink as expected
(with zeros between packets).
The problem arises when I change the center
frequency from zero to something higher (I use
LFTX/LFRX boards). Then, the received signal envelop
is corrupted like it's multiplied by some cosine
(see screenshot attached, all frames are supposed to
have the same height).
When I don't use the packet_len feature of the USRP
block or when my PHY block produces packets
continuously, the received signal is okay.
Why does this happen? Is my methodology of not
producing anything between packets is the right
approach?
Thanks in advance,
Roee
<Mail
Attachment.png>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|