discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] benchmark_xx Packets


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] benchmark_xx Packets
Date: Mon, 9 Mar 2009 16:54:00 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Mar 09, 2009 at 11:29:54PM +0100, William Sherman wrote:
> Hi,
> 
> I am planning to modify benchmark_xx to send and receive custom packets
> (similar to 802.11 packets).
> 
> I have been rooting around these two files. I would like to know: in
> benchmark_rx how does the radio "know" when it has received a packet
> (and call rx_callback). rx_callback is called by pkt.py I believe,
> demod_pkts. I looked at demod_pkts and I am still unclear how demod_pkts
> realizes it has a packet on its hands?
> 
> Thanking you in advance.

If you look at demod_pkts in pkt.py you'll see that it connects
together the chosen demodulator (passed in),
gr.correlate_access_code_bb and a gr_framer_sink_1.

gr_correlate_access_code_bb slides the given access code (usually an
M-sequence) across the demodulated bits, and produces two bits of
output for each input bit: the original bit, and a flag bit:

[from gr_correlate_access_code_bb.h]

    /*!
     * \param access_code is represented with 1 byte per bit, e.g., 
"010101010111000100"
     * \param threshold maximum number of bits that may be wrong
     */
    gr_correlate_access_code_bb_sptr 
    gr_make_correlate_access_code_bb (const std::string &access_code, int 
threshold);

    /*!
     * \brief Examine input for specified access code, one bit at a time.
     * \ingroup synch
     *
     * input:  stream of bits, 1 bit per input byte (data in LSB)
     * output: stream of bits, 2 bits per output byte (data in LSB, flag in 
next higher bit)
     *
     * Each output byte contains two valid bits, the data bit, and the
     * flag bit.  The LSB (bit 0) is the data bit, and is the original
     * input data, delayed 64 bits.  Bit 1 is the
     * flag bit and is 1 if the corresponding data bit is the first data
     * bit following the access code. Otherwise the flag bit is 0.
     */

gr_framer_sync_1 reads the output from gr_correlate_access_code_bb and
builds packets which it inserts into a message queue.

[from gr_framer_sync_1.h]

    gr_framer_sink_1_sptr 
    gr_make_framer_sink_1 (gr_msg_queue_sptr target_queue);

    /*!
     * \brief Given a stream of bits and access_code flags, assemble packets.
     * \ingroup sink
     *
     * input: stream of bytes from gr_correlate_access_code_bb
     * output: none.  Pushes assembled packet into target queue
     *
     * The framer expects a fixed length header of 2 16-bit shorts
     * containing the payload length, followed by the payload.  If the 
     * 2 16-bit shorts are not identical, this packet is ignored.  Better
     * algs are welcome.
     *
     * The input data consists of bytes that have two bits used.
     * Bit 0, the LSB, contains the data bit.
     * Bit 1 if set, indicates that the corresponding bit is the
     * the first bit of the packet.  That is, this bit is the first
     * one after the access code.
     */
    class gr_framer_sink_1 : public gr_sync_block


Did this help?

Eric




reply via email to

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