On 01/18/2014 09:46 PM, chris 0 wrote:
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
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
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