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

[David Halls]

sorry - I meant to say that adding the additional hack removed the rotation on the constellation eq'd by h2_est but not the rotation on the constellation eq'd by h1_est, thus there is still some timing issue. This can seen in the *.png

Aditya - am I to understand that you want to have perfect timing sync?

In my case I am happy to have a few samples offset, because the FDE can remove this problem, as long as the samples in the header where the channel taps are calculated are synchronized with those in the payload where the taps are applied.

________________________________________
From: David Halls
Sent: 21 January 2014 17:50
To: Martin Braun; address@hidden
Subject: RE: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

Thanks Martin and Aditya,

Yes Martin your recap is correct.

Indeed our solutions are hacks. I had an initial worry that not consuming all of the items would end up with some sort of back-log. I am not sure I can get my head around why this in fact doesn't cause a problem?! But it hasn't stopped me sleeping at night just yet.

BUT, as with all hacks, it has come back to bite me. The exact nature is *very* difficult to explain, but I have implemented a 2x1 MISO system, and this uses orthogonal headers, so in HPD it receives header from tx1, then header from tx2 (rather than moving straight to payload), then receives (a superimposed tx1 + tx2) payload.

The hack caused some kind of timing issue and so rotation of the superimposed constellation was caused if I tried to equalize the superimposed constellation with h1 or h2.

(N.B. I realise (x1h1 + x2h2 + n)/h2 does not give x1 or x2; I am working on Wireless (PHY) Network Coding and the receiver will soon be a relay performing Hierarchical NC)

Anyway, adding another hack of:

        case STATE_PAYLOAD:

          if (check_items_available(d_curr_payload_len, ninput_items, noutput_items, nread))
          {
               .........blah blah
          }
          else
          {
            // Bug-fix for rotation on EQ2
            consume_each(VARIABLE_TRIGGER);
          }

where VARIABLE_TRIGGER = 3.

I can't expect anyone to solve my specific problem - but if a more elegant fix to the initial problem was possible, then this would most likely resolve my issue too.

Many thanks,

David
________________________________________
From: address@hidden address@hidden on behalf of Martin Braun address@hidden
Sent: 21 January 2014 17:26
To: address@hidden
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

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


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

________________________________

NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

---

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

---