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:address@hidden]
> Sent: Tuesday, October 21, 2014 1:24 PM
> To: Nowlan, Sean; address@hidden; 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 address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|