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 B.; [email protected]
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=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+david.halls=removed_email_address@domain.invalid] on
behalf of Martin B. [[email protected]]
Sent: 21 January 2014 17:26
To: [email protected]
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 D. wrote:
<[email protected] mailto:[email protected]> 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
[email protected]
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