>> ################################################## >> # Variables
>> ################################################## >> self.tx_gain = tx_gain = 15 >> self.samp_rate = samp_rate = 200000 >> self.f_center = f_center = 1.47e9 >> self.device = device = "type=usrp2" >> >> ################################################## >> # Blocks >> ################################################## >> self.usrp_sink = uhd.usrp_sink( >> device_addr=device, >> stream_args=uhd.stream_args( >> cpu_format="fc32", >> length_tag_name="packet_len", >> channels=range(1), >> ), >> ) >> self.usrp_sink.set_samp_rate(samp_rate) >> self.usrp_sink.set_center_freq(f_center, 0) >> self.usrp_sink.set_gain(tx_gain, 0) >> self.usrp_sink.set_antenna("TX/RX", 0) >> self.blocks_vector_source_x_0 = >> blocks.vector_source_c((1,)*5, False, 1, []) >> self.blocks_stream_to_tagged_stream_0 = >> blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5, >> "packet_len") >> >> ################################################## >> # Connections >> ################################################## >> self.connect((self.blocks_vector_source_x_0, 0), >> (self.blocks_stream_to_tagged_stream_0, 0)) >> self.connect((self.blocks_stream_to_tagged_stream_0, 0), >> (self.usrp_sink, 0)) > It's not working either... I can still observe the carrier at the receiver. >> - You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's >> between bursts. > I am getting exactly one "U". Both for the code in my previous post as > well as for the above one. It really seems like the USRP is not > recognizing the stream tags. > There are a few things to consider with this flowgraph (as posted): 1) Your vector source is set to /not/ repeat. After your flowgraph terminates, is that when you observe the LO still running? 2) You're essentially sending a very short rectangular pulse modulated onto a carrier, which in the frequency domain would look like a sinc function centered at the carrier. Is this what you want, or are you just experimenting with the burst interface? 3) Is there a reason your burst pulses need to contain so few samples? Could you provide some information about what you're trying to do in your end application? Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On Behalf Of Marcus Müller Sent: Tuesday, October 21, 2014 1:41 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB Sean, interesting point. Frederik, How does your carrier look when you send bursts of >500 samples? Greetings, Marcus On 21.10.2014 19:29, Nowlan, Sean wrote: > I'm concerned that the problem Frederik is observing has to do with the very short burst he is sending, something like 5 samples. I suspect this requires 1 call each to work and tag_work per 5 sample burst, which seems like an awful lot of context switching and overhead. > > -----Original Message----- > From: Marcus Müller [mailto:mar...@hostalia.de] > Sent: Tuesday, October 21, 2014 1:24 PM > To: Nowlan, Sean; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>; Martin Braun > Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB > Hi Sean, aaah good catch! Yes, that's right; sob is safe. Cheers, Marcus On 21.10.2014 19:19, Nowlan, Sean wrote: > From Marcus: >> ... and that (wut) might be a bug, because it implies that, if the >> stream has both a time tag and a sob tag, the question whether the tx >> metadata has a time tag depends on in which order these tags are >> sorted on the the tag storage multimap. Which might be random, >> because tags are sorted only by tag offset. >> @Martin: is there a reason that this is explicitely set to false >> here, or can one just fix this by deleting a line? > This appears to be handled correctly. Given the same tag offset, the > order of tx_time vs. tx_sob tags should not matter. If tx_time is > found first, it sets found_time_tag=true and > _metadata.has_time_spec=true (lines 652 & 653). Then > _metadata.has_time_spec is overwritten in the tx_sob check (line > 665) with 'false', but is set back to 'true' in line 743 due to > found_time_tag being true. > if (found_time_tag) { _metadata.has_time_spec = true; } > If instead tx_sob is found first and tx_time second, then the time > spec will also be set in line 743. So the question is whether setting > _metadata.has_time_spec=false is really necessary. I'd say it's worth > keeping in case the user doesn't always want to use tx_time stamps. > The user may want to schedule some bursts but force others to transmit > as soon as possible while still using the ATR functionality of the > USRP. > I know all this logic can be hard to follow, but it has to handle so > many different cases and possibly span many calls to work and > tag_work. > From Frederik: >> Unfortunately, even with the newest version the USRP is still >> transmitting its carrier over the air. I tried both with the Message >> Burst Source as well as with the Stream to Tagged Stream Block >> combined with setting a Length Tag name in the USRP Sink. >> With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag, >> respectively. They all seem to be at the right place and have the >> right value. >> >> The Length Tag should arrive properly at the Sink. I checked by >> changing the tag's name at the Stream to Tagged Stream Block to >> something stupid and finally got an "tG" printed out. > It should be mentioned that there are two burst tag interfaces that > cannot be mixed. if a Length Tag Name is specified to the constructor, > all tx_sob and tx_eob tags will be ignored in tag_work to ensure the > interfaces are mutually exclusive. If no Length Tag Name is specified, > then tag_work will search for tx_sob/tx_eob tags and won't look for > length tags. > Sean > On 21.10.2014 15:53, Frederik Wing wrote: >> Hi Marcus, >>>>> I cannot believe that there is no solution to it since the >>>>> "tags_demo" application shows that it is indeed possible. >>>>> :-/ >>> that makes the two of us! I didn't get that when using tags_demo, >>> you're not seeing the carrier that you use tags_demo; as far as I >>> understood, your application does exactly the same, sending bursts >>> with sob/eob tags? >> >> That's right. tags_demo works perfectly. No carrier in between the >> bursts. The flow graph I posted before sends exactly one burst with >> SOB and EOB tags. The only difference to tags_demo I could recognize >> so far is that I don't assign time stamps to the samples. But this >> shouldn't be a problem, should it? >> >> Frederik >> >> >> _______________________________________________ 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<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