[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Requesting help with HPD block

From: Martin Braun
Subject: Re: [Discuss-gnuradio] Requesting help with HPD block
Date: Tue, 17 Mar 2015 14:21:28 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 17.03.2015 14:14, Richard Bell wrote:

Thanks for your detailed response. I need some clarification on a few
points. I also need to clarify something.

I am using the HPD on demodulated detected data. There are no floats at
this point. Everything is binary. The data type of all blocks is byte.

My bad,

my mind colour-mapped the type wrongly to floats.

I am adding artificial zeros in myself, after I form the packets, to
simulate a burst transmission. I send a packet, dead time (0's), I send
another packet, so on. That is the source of the zeros coming out of the
payload port.

OK, with that in mind, if my packet is setup accordingly:

packet_structure: [32 bit header | 128 byte = 1024 bit payload]

what are you calling an item here?

'Item' is GNU Radio nomenclature here. In your case, one item is one byte from the input buffer.

Question is, how many bits are in one byte in your input buffer? Is your 1024 bit payload really 128 bytes long on the input buffer?

Also, have you used the message debug block to see what your parser returns?


I am looking for the unit tests your mentioned. I was not aware of them.


On Tue, Mar 17, 2015 at 1:52 PM, Martin Braun <address@hidden
<mailto:address@hidden>> wrote:

    On 17.03.2015 11:48, Richard Bell wrote:

        My issue might stem from a misunderstanding of the HPD
        parameters. This
        block seems to have been written for OFDM, but I'm using it for
        carrier QPSK. If someone wouldn't mind looking over my
        parameters with
        singe carrier in mind to confirm I've set it up correct, I would be
        grateful. My header is 32 bits long and the payload is 160 bytes
        or 1280
        bits long. The documentation for this block is not very clear on
        how the
        parameters relate to the system.


    the block has some added features to handle OFDM, but it wasn't
    written specifically for it. If you haven't read the unit tests for
    this code, you should definitely go there for some input.
    (The reason OFDM was considered as a special case is because this
    makes a CP remover block unnecessary, but that's another story).

        The output of the header port is perfect. It is the exactly what I
        expect. I'm showing 3 headers worth of samples in the sink plot,
        and we
        see exactly 3 headers with tags on the first sample of each
        header. In
        the payload length portion of the header, the value 160 exists
        for the
        payload length. My second question is, when generating the
        header using
        packet_header_default, is the payload represented in bytes or bits?

    Whatever your payload parser generates should be the number of
    *items* read through the HPD. What are bits, bytes? The HPD doesn't
    know any of this. It can only relate to the item size you've given it.

        Now if you look at the payload out sink plot, you will see payloads
        separated by zeros. Each payload portion (the non-zero portion)
        is the
        exact length as my payload should be, 160 bytes or 1280 bits.
        But you
        can see zeros are allowed through after the 1280th bit and a second
        payload shows up without a tag. This leads me to believe the HPD
        is interpreting the payload length to be 4 times larger then I
        intend it
        to be. What parameters am I mixing up to create this?

    Yeah, I can see how that's happening. Your payload is being
    (probably correctly) interpreted as 160 bytes, then the HPD is given
    the number 160 as a payload length. However, the HPD needs to know
    the number of *items* per payload. 4 == sizeof(float), which you are

    The reason the OFDM code has no issues here is because it uses its
    own packet header parser, which returns the number of OFDM symbols.
    That really was the intention of the packet header parser architecture.

    Now, how come the packet header parser is reporting 160? Is that
    actually correct? It seems that if your payload is 40 floats, 160
    bytes seems a lot. You'd be storing 4 bytes per float, when
    typically, you have 1 or 2 bits.

    However, as a quick hack, edit the packet_header_default to add a
    scaling factor (or just divide by 4 before sending the packet). That
    should fix it temporarily. A more long-term solution would be to add
    a scaling factor to the packet_header_default for these cases --
    maybe you want to write and upstream this?

        I've played with the ofdm_tx/rx.grc example and confirmed that
        it will
        keep the zeros from showing up at the payload out port. This
        confirms my
        misuse of the block. The hard part is porting the OFDM example
        parameters to a single carrier use. Am I correct in setting
        symbol to 1
        since there are no OFDM symbols?

    Here's what should work:

    header length: Whatever you have now
    items per symbol:
    gi: 0
    output format: items

    Now make sure the header_parser tells the HPD the number of floats
    it needs to consume per payload.

    The value reported by the payload is the same unit as the header length.


    PS: The reason you see zeros between packets is because the
    ringbuffers get initialized with zeros to start with. Eventually,
    you might see residue from other packets.

    Discuss-gnuradio mailing list
    address@hidden <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]