[Top][All Lists]
[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