Header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

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.

Say we have 96B data this gives 768/48 = 16 data symbols. Adding 3
preamble gives 19×80 samples = 1520. Sometimes there are only 1519 or
1518 samples between triggers.

This means that in the HPD code, too many items are consumed by the
processing of the previous packet and thus the next trigger = 1 item is
consumed in error so it is never found.

A simple hack is to consume ‘x’ fewer samples in the HPD code I.e. In
the line

consume_each (d_header_len * (d_items_per_symbol + d_gi));

And the equivalent in the payload case, we can append ’ - 3’
A slightly more robust way would be to check where the next trigger
occurs and remove the corresponding number of times.

Are you able to recreate this issue? I realise that the problem only
occurs when using a different data source than the standard demo, so of
course it’s not a bug as such at all.

Many thanks,

David


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

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

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

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.

Absolutely; this is an unclean hack.

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.

Assume that the FFT size is 64 and the CP length is 16. As long as the
trigger comes within the first 16 time-domain samples, we should be
fine.

The following applies probably to my unique problem domain (which is to
design a better channel interpolation technique):

I would like the trigger to come in at exactly at the end of the CP, as
this would eliminate spurious channel rotations. If the trigger comes in
during the CP, we will see rotations in the frequency domain (the
channel
changes very quickly across subcarriers). To eliminate this, I would
like
the trigger to come in exactly at the end of the CP. In this case, a
trigger offset of 1-4 can cause the subsequent packet to not be detected
by
the HPD.

If your channel interpolation method is DFE, then these rotations are
irrelevant.

best,
aditya

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: [email protected]n.invalid
[[email protected]n.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

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: [email protected]n.invalid
[[email protected]n.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

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

Correct. This is because I want to study how the channel changes across
OFDM subcarriers (caused due to multi-path). Having rotations in the
channel across subcarriers caused by trigger timing offsets is what I
want
to eliminate.

best,
aditya

Ah, I see. You want to isolate the effect of the channel. I believe it
will be difficult, if not impossible, to remove the slight jitter of the
trigger, even in very high SNR - perhaps others can comment/help?


From: Aditya D. [[email protected]]
Sent: 21 January 2014 17:57
To: David Halls
Cc: Martin B.; [email protected]
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem
when using random bit stream (variable trigger location)

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

Correct. This is because I want to study how the channel changes across
OFDM subcarriers (caused due to multi-path). Having rotations in the
channel across subcarriers caused by trigger timing offsets is what I
want to eliminate.

best,
aditya


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

…having said that, I never saw the trigger jitter until I started
using a random data source rather than ‘range(packet_len)’, do you get
jitter in this case?


From: [email protected]n.invalid
[[email protected]n.invalid] on
behalf of David Halls [[email protected]]
Sent: 21 January 2014 18:03
To: Aditya D.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem
when using random bit stream (variable trigger location)

Ah, I see. You want to isolate the effect of the channel. I believe it
will be difficult, if not impossible, to remove the slight jitter of the
trigger, even in very high SNR - perhaps others can comment/help?


From: Aditya D. [[email protected]]
Sent: 21 January 2014 17:57
To: David Halls
Cc: Martin B.;
[email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem
when using random bit stream (variable trigger location)

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

Correct. This is because I want to study how the channel changes across
OFDM subcarriers (caused due to multi-path). Having rotations in the
channel across subcarriers caused by trigger timing offsets is what I
want to eliminate.

best,
aditya


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/trlhttp://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



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

On Tue, Jan 21, 2014 at 1:03 PM, David Halls
[email protected]wrote:

Ah, I see. You want to isolate the effect of the channel. I believe it
will be difficult, if not impossible, to remove the slight jitter of the
trigger, even in very high SNR - perhaps others can comment/help?

Yes, that is correct. It is impossible to eliminate the jitter in
triggers from Schmidl-Cox. But I want to minimize it, and have edited
the
plaueau/peak detector code to do just that. (all in a hackish manner!)

Dear Martin,

Thanks for the ideas.

Two ideas:

  • You could remove the sync block and sync your rx/tx paths with other
    means (e.g. MIMO connector, it depends on your hardware). This makes the
    sync influence independent of the noise.

Good idea, I will try it out once I get the cables.

  • Reconsider if the phase rotation really makes your measurements
    invalid. You’ll have a phase rotation in any case (due to channel,
    propagation time etc.). The timing-related phase offset is constant,
    after all, and the phase difference between sub-carriers depends on the
    sub-carrier distance, too. Perhaps it doesn’t matter all that much?

That makes sense. I want to study the different phenomena that affect
phase
rotations in the channel. By eliminating the USRP hardware (by
connecting
the TX and RX blocks to each other through a channel model block), I can
control the PDP of the simulated channel, for example.

Thank you for your inputs. This is very useful to me.

best regards,
aditya

Dear Martin,

I wondered, if you are working on the HPD, if it’s possible to look into
making a change when a header is received incorrectly, e.g. low SNR or
sudden shadowing. I find that (although it no longer crashes with the
recent update to adjust buffer size) it loses synchronisation and does
not recover in later packets. I can’t quite work out why…

Regards,

David

From: [email protected]n.invalid
[mailto:[email protected]n.invalid]
On Behalf Of Aditya D.
Sent: 22 January 2014 15:02
To: Martin B.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem
when using random bit stream (variable trigger location)

Dear Martin,

Thanks for the ideas.

Two ideas:

  • You could remove the sync block and sync your rx/tx paths with other
    means (e.g. MIMO connector, it depends on your hardware). This makes the
    sync influence independent of the noise.

Good idea, I will try it out once I get the cables.

  • Reconsider if the phase rotation really makes your measurements
    invalid. You’ll have a phase rotation in any case (due to channel,
    propagation time etc.). The timing-related phase offset is constant,
    after all, and the phase difference between sub-carriers depends on the
    sub-carrier distance, too. Perhaps it doesn’t matter all that much?

That makes sense. I want to study the different phenomena that affect
phase rotations in the channel. By eliminating the USRP hardware (by
connecting the TX and RX blocks to each other through a channel model
block), I can control the PDP of the simulated channel, for example.

Thank you for your inputs. This is very useful to me.

best regards,
aditya


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

On 01/23/2014 03:21 PM, David Halls wrote:

I wondered, if you are working on the HPD, if it’s possible to look into
making a change when a header is received incorrectly, e.g. low SNR or
sudden shadowing. I find that (although it no longer crashes with the
recent update to adjust buffer size) it loses synchronisation and does
not recover in later packets. I can’t quite work out why…

Hi David,

I’m not seeing this. I can turn the tx on and off and the rx will
happily run. Try this branch and tell me if you still see the problem:
https://github.com/mbr0wn/gnuradio/tree/hpd-timing

Are you sure this is not just GRC no longer outputting info? The GRC
console buffer is limited, and you have to restart GRC in this case.

MB

On 01/21/2014 07:16 PM, Aditya D. wrote:

the plaueau/peak detector code to do just that. (all in a hackish manner!)
Hm, this will be hard to get right. After all, the Schmidl & Cox is an
estimator and operates on noisy values. Unless your SNR is crazy good,
there is always a chance of getting it wrong. And technically, even
then.

Two ideas:

  • You could remove the sync block and sync your rx/tx paths with other
    means (e.g. MIMO connector, it depends on your hardware). This makes the
    sync influence independent of the noise.

  • Reconsider if the phase rotation really makes your measurements
    invalid. You’ll have a phase rotation in any case (due to channel,
    propagation time etc.). The timing-related phase offset is constant,
    after all, and the phase difference between sub-carriers depends on the
    sub-carrier distance, too. Perhaps it doesn’t matter all that much?

MB

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