# Header Payload Demux Freeze

**URL:** <https://www.ruby-forum.com/t/header-payload-demux-freeze/241865>\
**Category:** GNU Radio\
**Created:** [May 6, 2015, 9:20pm UTC](https://www.ruby-forum.com/t/header-payload-demux-freeze/241865 "2015-05-06T21:20:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [May 6, 2015, 9:20pm UTC](https://www.ruby-forum.com/t/header-payload-demux-freeze/241865/1 "2015-05-06T21:20:42Z")

</div>

Hello all,

I’m experiencing some odd behavior with the Header Payload Demux (HPD)  
block. I’m using a Tx/Rx loopback simulation with full synchronization  
and  
channel model in the loop. The simulation begins with all channel model  
parameters turned off. For the sake of this discussion, the channel will  
always be in the off state.

When I start the simulation, it will sometimes run for over a minute  
before  
I see the HPD output freeze and sometimes only for a second or two. The  
freeze always starts at the HPD block, and then as buffers fill, all the  
preceding blocks become frozen (frozen in the sense that all outputs  
stop  
changing as seen on Qt GUIs). GNU Radio itself does not freeze. I have  
placed a message debug block to display the Packet Header Parser  
messages  
and I always see that this stops updating first. The messages will be in  
a  
good state, identifying packet number and payload length and then  
suddenly  
just stop. No more messages at all.

I’m not sure what’s causing this behavior. Does anyone have an idea? I’m  
happy to provide more information.

v/r,  
Rich

---

<div class="post-metadata">

**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:** [May 6, 2015, 9:54pm UTC](https://www.ruby-forum.com/t/header-payload-demux-freeze/241865/2 "2015-05-06T21:54:00Z")

</div>

If your packet header parser stops outputting messages, then that would  
lock up the HPD. If the HPD is waiting for a message from the header  
parser, it doesn’t have any other choice.

Question is why the parser isn’t outputting any message. I’m guessing  
that the HPD does output the header information, but then that gets  
stuck in the header branch somehow. Can you check that?

M

---

<div class="post-metadata">

**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:** [May 7, 2015, 7:57pm UTC](https://www.ruby-forum.com/t/header-payload-demux-freeze/241865/3 "2015-05-07T19:57:13Z")

</div>

Yes I agree. If it is the case that the Packet Header Parser does not  
output a message for every header it is given, would that produce the  
“backup” behavior I’m seeing? Backup meaning it looks like the buffers  
on  
all preceding blocks start to fill up because the HPD block is stock in  
a  
blocked state. This eventually leads to all blocks being in a blocked  
state  
because their buffers are full. This is my interpretation.

Given that I am using digital.packet\_header\_default(32, “packet\_length”)  
to  
define the header, Packet Header Generator to output the header as a  
stream  
and Packet Header Parser to create the messages from the stream, do you  
have an idea of what could be going wrong? Maybe a better question would  
be, under what circumstance would the Packet Header Parser be given a  
stream and not output a message?

v/r,  
Rich

On Wed, May 6, 2015 at 12:52 PM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**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:** [May 7, 2015, 8:58pm UTC](https://www.ruby-forum.com/t/header-payload-demux-freeze/241865/4 "2015-05-07T20:58:34Z")

</div>

On 07.05.2015 10:56, Richard B. wrote:

> do you have an idea of what could be going wrong? Maybe a better  
> question would be, under what circumstance would the Packet Header  
> Parser be given a stream and not output a message?

This _should_ only happen if the parser doesn’t get enough samples for a  
full header. It will always output something, even if parsing fails.

M