Re: [Discuss-gnuradio] OFDM GRC block attempt

[Johnathan Corgan]

Josh Blum wrote:

> Its not quite that. I should explain. The packet modulator block in 
> blks is weird for another reason, it takes another gnuradio block (a
>  modulator) as an argument in the constructor. The problem being that
>  this does not fit into GRC too well.

OFDM is itself a modulation format, but each of the sub-carriers has
their own channel modulation scheme.  So we have to pass a modulator
into the OFDM block so it knows what to use to map incoming bits into
channel symbols for each sub-carrier.  This isn't weird; it's how OFDM
works.

> However, the "new" blks2 packet modulator has an io signature that 
> requires a byte input and a complex output.

If you are referring to blks2.mod_pkts, it's signature takes no inputs,
and outputs complex baseband.  You send it a payload via send_pkt().

If you are referring to the various digital modulator blocks, like
blks2.dqpsk_mod(...), then these all take a stream of bytes and output
complex baseband.  So the io signature you describe is the correct one.

> I think it is best to just make my own packet modulator block that 
> uses the code from the blks2.
> 
> This implementation of the packet modulator will take a data stream 
> (of any type), read data from a message sink, packetize, write data 
> to a message source. Then, a modulator (like dpsk) could be connected
>  to the output of this packet modulator using top_block.connect.

This would work, to take an arbitrary data stream and break it up into
packets for transmission. But...

> Maybe it would be useful to have a packet modulator/demodulator that
> fits into the typical gnuradio block model?

The "typical gnuradio block model" is that of a stream-based data flow,
with no boundaries.  Digital packet data has boundaries by definition.
Up until now we deal with this by turning specific lengths of bytes in a
stream into a "message" that gets sent to the packetizer, which then
formats the header, CRC, whitening, FEC (future), etc.

> Also, I was under the impression that the mblocks will eventually
> implement this kind of functionality (packets, error encoding,
> recovery..).

Yes.  The message block (m-block) data model is passing defined lengths
of data between I/O ports in a flow graph of blocks.  It was entirely
motivated by this more natural method of dealing with packet data and
meta-data.

So, once the m-block infrastructure is more mature, we'll be able to
re-write all the packet handling code in such a way that the
modulation/demodulation functions occur in the gr-block data flow model
and the packet handling, MAC layer, etc., occur in the m-block world.

Conceptually, a digital modulator will be a hybrid block that accepts
raw frame data as m-block messages and outputs a complex baseband data
stream.  A digital demodulator will accept a complex baseband data
stream and emit m-block messages containing raw frame data.  This is
very similar to the existing blocks except today we use gr_message's
instead of m-block messages.

The basic m-block code and infrastructure is in the trunk, but it is
undocumented and incomplete.  If you look through the QA code you can
see how to create your own m-blocks and wire them up much in the same
way you do with gr-blocks.

As an aside, the "in-band signaling" feature that is slated for release
3.2 depends upon m-block code, so you'll see it in use then.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com