Re: [Discuss-gnuradio] Using Header/Payload Demux

[Martin Braun]

On 01/18/2014 09:46 PM, chris 0 wrote:
> Hi,
> 
> I'm wondering if anyone can take a look at my grc file, which uses the
> header/payload demux to try to obtain a payload - but I'm currently
> getting incorrect values from the tags.  For instance  packet_len should
> be 10, but the value is mostly 1.
> 
> I've attached the file.
> 
> If you can't open it from the email i've also uploaded to -
> http://www.anfractuosity.com/files/mux2.grc

Hey Chris,

nice to see people using this block! Outside of the OFDM scope, it
hasn't yet received too much attention.

A couple of comments:
- The CRC block increases the packet length by 4. This means packet_len
*should* be 14. I ran the simulation, and that's what it was -- so it
seems your code is working. However, the repacker thinks '14 bits', and
will then produce 1 byte at the output (because floor(14/8)==1, and we
have that 'floor' because the alignment is set to 'output'). That's why
you see 1 item at the first tag debug.
- In your setup, there is no mechanism that tells the receiver that '14'
actually means '14 bytes', not '14 items'. The payload length is
*actually* 14*8==112! This means the stream crc check block will never
get the right data to work on.

The latter problem is easy to fix in your case. Simply use a
tagged_stream_multiply_length block after the demux, before the repacking.

In the OFDM case, this is more complicated, because the number of OFDM
symbols and the number of data symbols is not necessarily an integer
multiple of one another. Here, a more elaborate solution is used: The
packet header formatter object is inherited from and modified to produce
both tags at the payload output.

Apart from that, you're model is correct, and a good simple example for
the demuxer!

A hint for debugging: Use more tag debugs, with different names, not
only at the rx path, but also on tx. This way, you can identify problems
very quickly.

MB