Re: [Discuss-gnuradio] Question Regarding GMSK2 examples

[Eric Blossom]

On Mon, May 01, 2006 at 09:42:01PM -0400, Michael Dickens wrote:
> On Monday, May 1, 2006, at 08:21 PM, Elaine Garbarine wrote:
> >As a related question, does rx_callback only exist if the packet is 
> >received
> >properly (i.e. without errors)?
> 
> In essence, yes: the rx_callback will only be called when a packet is 
> received without (*) errors.  See 
> .../gnuradio-core/src/lib/general/gr_packet_sink.cc and it's work() 
> method and finite-state-machine-ish code if you really want the 
> in-depth story.
> 
> (*) This happens when enough of the sync bits are correct (either the 
> user-supplied value or the default of 12 bits wrong out of 64) and the 
> immediately-following 32-bit header is correct (meaning that the first 
> 16 bits and second 16 bits are identical [correct or not], and that the 
> payload length [the integer value of either of the first or second 16 
> bits] is <= 4096).  Note that the "function" 'slice()' could more 
> reasonably be called "hard_decode_bit()" since that's what it does.
> 
> ps> As a general question regarding the gr_packet_sink, why does this 
> have to do it's output via a gr_message inserted into a queue?  Why not 
> stream the output to the next block in the flow graph style?

Because flow graphs, as currently constituted, do a terrible job with
variable length chunks of data.  Hence the BBN design-in-progress on
the m-block extension.

> Is this  one of the "message versus stream" issues that BBN's proposal will 
> address?  

Yes.

> Or is it something to do with carrier recovery and such?  Or was the
> carrier issue why the gmsk2_mod_pkt required queued packets and not
> a stream?

It was all to support variable length packets within the existing GNU
Radio framework.

Eric