Hi Martin, First of all, many thanks for your last reply, it was extremely helpful!
I'm just having a little bit of a problem with your suggestion to scale the tag length, which I'm doing using a length scalar of 8. Tag Debug: Rx Bytes Input Stream: 00 Offset: 0 Source: n/a Key: packet_len Value: 14 Offset: 0 Source: n/a Key: packet_num Value: 0 Offset: 1 Source: n/a Key: packet_num Value: 1 Offset: 1 Source: n/a Key: packet_len Value: 112 Offset: 3 Source: n/a Key: packet_num Value: 2 Offset: 3 Source: n/a Key: packet_len Value: 112 Offset: 5 Source: n/a Key: packet_num Value: 3 Offset: 5 Source: n/a Key: packet_len Value: 112 Offset: 7 Source: n/a Key: packet_num Value: 4 Offset: 7 Source: n/a Key: packet_len Value: 112 Offset: 8 Source: n/a Key: packet_num Value: 5 Offset: 8 Source: n/a Key: packet_len Value: 112 Offset: 10 Source: n/a Key: packet_num Value: 6 Offset: 10 Source: n/a Key: packet_len Value: 112 Offset: 12 Source: n/a Key: packet_num Value: 7 Offset: 12 Source: n/a Key: packet_len Value: 112 For some reason the first packet_len is still 14, rather than 112, which is confusing me. Thanks a lot. Chris On Mon, Jan 20, 2014 at 9:09 AM, Martin Braun <martin.br...@ettus.com>wrote: > 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 > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
mux2.grc
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
