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
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
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. [email protected]
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