Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
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: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Aditya Dhananjay Sent: 22 January 2014 15:02 To: Martin Braun Cc: discuss-gnuradio@gnu.org 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
On 01/21/2014 07:16 PM, Aditya Dhananjay wrote: On Tue, Jan 21, 2014 at 1:03 PM, David Halls david.ha...@toshiba-trel.com mailto:david.ha...@toshiba-trel.com 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!) 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
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.comwrote: 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 -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
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 MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
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
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 Dhananjay [adi...@cs.nyu.edu] Sent: 21 January 2014 17:57 To: David Halls Cc: Martin Braun; discuss-gnuradio@gnu.org 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
...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: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of David Halls [david.ha...@toshiba-trel.com] Sent: 21 January 2014 18:03 To: Aditya Dhananjay Cc: discuss-gnuradio@gnu.org 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 Dhananjay [adi...@cs.nyu.edu] Sent: 21 January 2014 17:57 To: David Halls Cc: Martin Braun; discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
On Tue, Jan 21, 2014 at 1:03 PM, David Halls david.ha...@toshiba-trel.comwrote: 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!) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
