# Requesting help with HPD block **URL:** \ **Category:** GNU Radio\ **Created:** [March 17, 2015, 7:50pm UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617 "2015-03-17T19:50:24Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 17, 2015, 7:50pm UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617/1 "2015-03-17T19:50:24Z")
Gnuradioers, I continue to struggle to get the Header/Payload Demux (HPD) block to work properly. The header output port is perfect while the payload output port is not. The payload output port is full of 0’s that should not be there. I cannot figure out the reason why. I have attached a screenshot of my HPD config and the time sink outputs of the header port and payload port, as well as screenshot of the complete flowgraph. 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. 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? 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? 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? v/r, Rich ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [March 17, 2015, 9:54pm UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617/2 "2015-03-17T21:54:34Z")
On 17.03.2015 11:48, Richard B. 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. ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [March 18, 2015, 3:29pm UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617/3 "2015-03-18T15:29:46Z")
On 17.03.2015 14:14, Richard B. 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 ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [March 19, 2015, 11:01am UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617/4 "2015-03-19T11:01:02Z")
On 17.03.2015 14:46, Richard B. 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 ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [March 19, 2015, 5:28pm UTC](https://www.ruby-forum.com/t/requesting-help-with-hpd-block/234617/5 "2015-03-19T17:28:25Z")
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 B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)