discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Date: Tue, 21 Oct 2014 19:23:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>> 
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ 
> Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K 
> pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi 
> MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L 
> G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3 
> L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8= 
> =V3EN -----END PGP SIGNATURE-----
> 
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp7q1eKTr3Bm
hq4P6pIAXxXkmIRWVy+pn2uZ2zunvv0/2e/NcE4RMppuxTlT8HvjeKb0aKDMIxE2
spVqN/nuue5JSRAbQJIvI69jJytGgqzxvjY2EyWHSZPKtXB3Hc5a/PoMGY3EZb45
hZ+mYN0z6JpUhRlozinTkkRI3D/P38dubx5YXTSbzCthEt2BMMInS+FEpiH42KrI
rKP7ywwqL0O6TFvFMlOqn9hNzJKP+PFvoJQbuH3zJSItIeRbyIth6QwERNh8Pg0H
3U19h6Y7ejnh+G8UOSOdxnlsoLHzwloYEvUb1cvBbhKeyDd4Dng8DwPa+Q6T0qo=
=vsQm
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]