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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
