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)
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
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
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.
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
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
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
.
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
]
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
+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
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?
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
12 matches
Mail list logo
