discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] packet encoder/decoder input-output rate


From: Josh Blum
Subject: Re: [Discuss-gnuradio] packet encoder/decoder input-output rate
Date: Fri, 02 Mar 2012 17:26:06 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0

> 
> Does the packet encoder needs to continuously have samples at its input to
> generate a packet? Or can we send information to the packet encoder at very
> low rate, and the packet encoder will just generate one packet and sleep
> again until the next information comes in? 
> 
>  

If you have an infinite source of data, the packet encoder and
downstream blocks will back-pressure your data source once internal
buffering is full. This "infinite source" was kind of the intended use
for packet encoder since gnuradio doest have much in the way of
implementing a message passing layer, so this was a way to do it in grc.

If you dont have an infinite data source, you really need to end the
burst when data is not available. This isnt really built into the packet
encoder. The basic idea is that you set an end of burst tag on each
packet, or when you know there is no more continuous data.

If you dont end the burst when there is no data, the usrp produces an
underflow. Underflow is technically an error, but it might be ok if let
underflows happen.

If you want to end the burst properly, here is the docs about tagging on
the sink block:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n59

Supposing you were to set an end of burst tag, I would recommend putting
it here (i'm recommending it on this branch, since you cant make tags in
python from master):
http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=msg_passing_squashed#n77

-Josh



reply via email to

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