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; discuss-gnuradio@gnu.org
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: discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org
[discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org] on behalf of
Martin Braun [martin.br...@ettus.com]
Sent: 21 January 2014 17:26
To: discuss-gnuradio@gnu.org
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
> <david.ha...@toshiba-trel.com <mailto:david.ha...@toshiba-trel.com>> 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
Discuss-gnuradio@gnu.org
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
---------------------------------------------------------------------------------------
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
