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 On 15 Nov 2015, at 08:19, Marcus Müller <marcus.muel...@ettus.com> wrote: 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 >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
