discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Richard Bell
Subject: Re: [Discuss-gnuradio] Requesting help with HPD block
Date: Wed, 18 Mar 2015 16:20:38 -0700

Martin,

Bingo! That worked.

Can you put those two numbers, 4 and 8 into words. I'm still having a heck of a time understanding what is going on with this block.

v/r,
Rich

On Wed, Mar 18, 2015 at 9:54 AM, Martin Braun <address@hidden> wrote:
On 17.03.2015 14:46, Richard Bell wrote:
Each byte going into the HPD is an unpacked byte. There is only 1 bit
represented per byte. Receiving the full payload of 1024 bits requires
1024 bytes of input. What does this imply for the HPD parameters?

By setting it up with
header_length = 1 (symbol)
items per symbol = 32 (the header length)

Try this:

Make the header_length 4 and items per symbol 8. Then, the message from the parser will match the number of items.

"Items per symbol" is something that would be mainly useful for non-atomic modulations, such as OFDM. It might do the trick here, too.

M



It produces the correct number of samples at the header output. Is it
possible for this to be working if the parameters were not set
correctly? I'm so confused.

Yes I've spit the messages out with a message debug port. The packet
length it reads is 128.

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

    On 17.03.2015 14:14, Richard Bell wrote:

        Martin,

        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?

    M

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

        v/r,
        Rich

        On Tue, Mar 17, 2015 at 1:52 PM, Martin Braun
        <address@hidden <mailto:address@hidden>
        <mailto: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
                 single
                 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.


             Richard,

             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
                 block
                 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
             using.

             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.

             M

             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@hiddenorg>
        <mailto:address@hidden__org
        <mailto:address@hiddenorg>>
        https://lists.gnu.org/mailman/____listinfo/discuss-gnuradio
        <https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>

        <https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio
        <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>







reply via email to

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