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