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 >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > 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
