Martin thanks for you reply.

I was looking at things wrongly. Now, I ask the scheduler for atleast 1000
samples at a time, using set_output_multiple() and I adjust the tag value
if overflow occurs.Thanks again for correction.

--
Bob


> If you change the size of a tagged stream without changing the tag,
> you're producing invalid data. (This may change on 3.8, we haven't
> finalized any decisions yet).
>
> However, how are you dropping samples in software? Or are you dropping
> them in hardware, in which case why are you not tagging the streams
> correctly?
>
> M
>
> On 06/22/2016 12:10 AM, bob wole wrote:
> > Thanks Martin,
> >
> > I know the packet size a priori but samples may drop due to overflows
> > while flowgraph is running and could result in different packet size. Is
> > there a way to solve this issue while using tagged_stream_block?
> >
> > --
> > Bob
> >
> >
> >     It'll crash. If you know your packet size a priori, you can tell the
> >     scheduler to only provide multiples of a 1000 samples.
> >
> >     Cheers,
> >     M
> >
> >     On 06/20/2016 07:17 AM, bob wole wrote:
> >     > Hi,
> >     > My  flowgraph contains a tagged_stream_block, B, and it has a
> >     > length_tag_key, say "pkt_len". Each packet has a length of 1000
> >     samples.
> >     > The upstream block (A-->B) tags first sample with key "pkt_len" and
> >     > value 1000 and then the upstream block tags sample number 901 with
> key
> >     > "pkt_len" and value 1000 instead of tagging sample number 1001.
> This
> >     > could happen in case of overflow and I know using receive tags
> >     that 100
> >     > samples has been lost. So, samples from 901 to 1900 contains a new
> >     > packet. Will the flowgraph work or will it crash?
> >     >
> >     > I want to write a block that processes exactly only 1000 samples,
> one
> >     > packet, in a call to work. And the packets start from a specific
> time
> >     > for example when the rx_time of the sample is mid of any second.
> >     >
> >     >
> >     > --
> >     > Bob
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to