| 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. 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.
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@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio |