Header/Payload Demux Bug Fix

Martin et. al.,

The fix that makes this block work for us in any scenario, is to add a
break statement at the end of every case statement (don’t allow the fall
through’s to happen).

This leads me to believe the source of the issues comes from the way
offsets are calculated between states within one general_work call.
Letting
general_work return after every state resolves any of these issues. I
think
this points to check_items_available as the problem child, but I
couldn’t
confirm that.

The testbench I use to confirm this has the built-in HPD block and my
custom HPD block, which has break statements at the end of each state.
The
built-in HPD block will start producing errors seconds after I start the
flowgraph. With the built-in disabled and my custom block in the same
flowgraph, it will run indefinitely (tested for 20 hours).

The settings of both blocks were:

Header Length: 8

Items per Symbol: 8

Length tag key: “packet_length”

Output Format: Items
IO Type: Complex
Trigger Tag Key: blank

The input to HPD is unpacked and the header is 64 bits long when packed.
I
did the bulk of testing using a custom tag_trigger block that outputs a
1
when it sees a certain tag and 0 otherwise to feed the detect port of
HPD.
I just tried it using the Trigger Tag Key of the HPD block itself and it
also seems to be fine. So either way seems to work.

I looked at the bug submission instructions, I think forking from github
is
the easiest way of doing it, but I need a little clarification. In this
case, am I correct to fork the repo, add the break statements to the HPD
source, and request a pull along with this explanation? I won’t be
adding
QA tests or anything else.

v/r,
Rich

Hey Richard,

good work! Did you also test this patch with the OFDM tx/rx example, or
some other settings to make sure this didn’t just fix your setup?

I’m a bit annoyed with myself for not getting the offset calculations
right. Maybe there’s another fix that won’t add breaks, but frankly,
let’s get this block right before we get it fast.

So, in order to get your changes in, you fork GNU Radio on github, push
your patch there, then submit a pull request. Read also this:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

If this is a bigger patch, we’ll need a copyright assignment. But we’ll
tell you if that’s the case.

Thanks!

Martin

I tested it with the rx_ofdm example and it works as it did before
(didn’t
test over several hours however).

Making the pull request now.

Rich

On Mon, Jun 1, 2015 at 11:13 AM, Martin B. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs