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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
