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 > > On 15 Nov 2015, at 08:19, Marcus Müller <marcus.muel...@ettus.com > <mailto: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 >>>> 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 <mailto: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
