Re: [Discuss-gnuradio] packet_header_default formatter packet length - why constant?

[Martin Braun]

Steven,

this is a tricky one. It took me a while to make sense of this stuff
(despite having written it) which is already a bad sign in terms of
documentation.

Here's the long story: When specifying 'header length', we never specify
the *unit*. Now, one thing is important: The header_len() method *must*
return the number of items, because that's important for the block to
function properly. So it mustn't return the number of bits, but the
number of symbols (which is what you're saying, too). The constructor
now also has a header_len parameter, and it means the same thing as
header_len().

When I was writing this, I had the default *and* OFDM header objects in
mind. The latter are a bit more tricky, and it's important to figure out
the number of OFDM *symbols*. However, these special header
formatter/parser objects are subclasses of the default class, so it's
not a simple matter to just change things.

I need to take a closer look at this. At the very least, documentation
needs fixing. But there's probably also a bug in there somewhere. And
maybe there's even a way to un-kludge this without breaking too much and
making it useful for all types of modulation.

Cheers,
M

On 04/23/2016 07:57 AM, Steven Knudsen wrote:
> Hi,
> 
> I have created a packet header that subclasses
> gr::digital::packet_header_default and so far so good.
> 
> In trying to understand the base class behaviour, I created a simple
> header packet generation GRC project that multiplexes a header with a
> payload.
> 
> The header_formatter is defined as
> digital.packet_header_default(32,legnth_tag_key) where length_tag_key is
> set to “packet_len”; this is the same as many examples, obviously.
> 
> The header packet generator works fine with this, generating a 32 byte
> header with 1 bit of header data per byte. This makes sense since I left
> the default bits_per_byte in the header_formatter, which implies a BPSK
> modulator is used for the header.
> 
> However, if I change the header_formatter to
> digital.packet_header_default(32,legnth_tag_key,num_tag_key,header_mod.bits_per_symbol())
> where num_tag_key is “packet_num” and header_mod is defined as
> digital.constellation_qpsk(), which means now 2 header bits per byte are
> encoded, the header generator still outputs 32 bytes and a packet_len =
> 32. Shouldn’t 16 bytes be output and packet_len = 16?
> 
> Accounting for the bits per symbol would make sense a) because that is
> consistent with the packet_header_default constructor bits_per_byte
> argument and b) it would be consistent with the behaviour of other
> blocks, such as Repack Bits, that are commonly used with packet blocks.
> 
> Anyone have an explanation? Perhaps I am not following GNU Radio
> philosophy in this approach?
> 
> BTW, in my packet header class I simply override the
> packet_header_default::header_len() to return the right number of bytes.
> That seems right to me :-)
> 
> Thanks!
> 
> steven
>  
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
> 
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
> 
> 
> All the wires are cut, my friends
> Live beyond the severed ends.  Louis MacNeice
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>