Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[Martin Braun]

On 01/21/2014 05:55 PM, Aditya Dhananjay wrote:
> Hello David,
> 
> I was facing the exact same issue, and the fix I use is identical to
> yours. I consume 4 symbols less than I need to, so the subsequent packet
> is not lost.
> 
> Best,
> Aditya
> 
> On Tue, Jan 21, 2014 at 11:14 AM, David Halls
> <address@hidden <mailto:address@hidden>> wrote:
> 
>     Hi Martin,
> 
>     Making good progress with the relay but on another topic, I find if
>     I use a random data source (rather than the 1...range in the
>     original example) the trigger signal arrives occasionally one or two
>     samples earlier than expected.

Yes, I have seen this happen. To recap (please correct me if this is in
fact not exactly your problem):

Say the input signal looks like this:

1 1 1 1 1 1 1 2 2 2 2 2 2 2 2    <- items
^             ^                  <- triggers

...everything is fine. Now, the trigger might be early (because of noise
etc.):

1 1 1 1 1 1 1 2 2 2 2 2 2 2 2    <- items
^           ^                    <- triggers

In this case, the trigger is consumed with the first packet, and the
second one can't be won't be detected.

Your solution will work, but you have to admit it's a hack. Who says my
payload is 3 or 4 symbols long? I'm currently working on the HPD, and
I'll figure out a way to get this in.
I guess not consuming the last symbol would be sufficient in most cases,
and since a payload must have at least one, this would be OK. For OFDM,
this must work since one OFDM symbol is longer than the detection timing
ambiguity.

MB