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