Thanks Jeff,
The block is a sync block as it should take in one vector and pass out
one vector, of the same size. The get_tags_in_range should be OK too.
Again as its one vector coming in there is only one 'item' at a time too.
tags = self.get_tags_in_range(0,self.nitems_read(0),self.nitems_read(0)
+ len(input_items[0]),pmt.string_to_symbol("ofdm_sync_chan_taps"))
As I said it worked fine on my ancient GNU Radio version.
I have pinned down the problem, as it occurs *before* my block. When I
put a 'tag_debug' after the 'stream_to_vector' block that precedes my
Python block, there are only half the number of tags in the first
vector, than are produced by a 'tag_debug' block placed before the
'stream_to_vector' block.
Of course when it is a stream the tags are spread over a number of
items, these create just one vector which 'scoops' up all these tags and
puts them onto the single item that represents the vector.
In the 2nd and onwards vectors there are the right number of tags, but
the first half are from the previous vectors worth of items.
Thanks,
David
________________________________________
From: address@hidden
<mailto:address@hidden>
<address@hidden> on
behalf of Jeff Long <address@hidden>
Sent: 10 September 2015 16:46
To: address@hidden <mailto:address@hidden>
Subject: Re: [Discuss-gnuradio] Scheduler and Tags - HELP!
Do you have a forecast() function defined in your block? If not, the
scheduler will call it with however many items it has available at the time.
Tags would be propagated by stream_to_vector at the same time it copies
items to its output buffer. Your block would need to specify the
appropriate start/end in get_tags_in_range().
- Jeff
On 09/10/2015 10:49 AM, David Halls wrote:
> Dear All,
>
>
> I have found more closely the issue.
>
>
> When the first burst is received, the block that does
> 'stream_to_vector', only copies the first half of the tags contained
> within the range of items.
>
>
> For subsequent bursts the correct number of tags are copied, but
> starting with the second half of those that should be in the first
vector.
>
>
> Can anyone suggest what's going wrong?
>
>
> Regards,
>
>
> David
>
>
> ------------------------------------------------------------------------
> *From:* David Halls
> *Sent:* 10 September 2015 12:56
> *To:* address@hidden <mailto:address@hidden>
> *Cc:* address@hidden <mailto:address@hidden>
> *Subject:* Scheduler and Tags - HELP!
>
> Dear All,
>
>
> I have recently updated my GR from a prehistoric version. I am having
> some problems related to scheduling/tags.
>
>
> I have a Python block that takes in vectors of 7680 complex items. This
> is made up of 10 packets, each with 16 OFDM symbols with 48 data
> carriers each.
>
>
> I am sending just 10 packets, one burst, and in my old GR version this
> block would then be called once, and only once, and all tags would be
> present (each symbol, i.e. every 48th item, is tagged with the channel
> taps). I
>
>
> n the new version of GR (no other changes), it is now called TWICE, and
> the first time only the tags from the first 5 packets are available,
> although the ITEMs for all 10 seem available.
>
>
> This almost seems like some kind of parallelisation, that the block is
> being called before the tags are completely applied by a preceding
> block. Can anyone help at all? I can of course provide code...
>
>
> Many thanks,
>
>
> David
>
>
> ------------------------------------------------------------------------
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
<http://www.toshiba.eu/research/trl>
>
>
>
> ------------------------------------------------------------------------
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden <mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
________________________________
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
<http://www.toshiba.eu/research/trl>
------------------------------------------------------------------------
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
------------------------------------------------------------------------