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