Forum: GNU Radio Fwd: Questions on rx_ofdm example in GR 3.7.1

236f0abc059f76b3054b16ef0af32bd4?d=identicon&s=25 "Daniel Domínguez" <eontool@gmail.com> (Guest)
on 2013-09-26 01:59
(Received via mailing list)
Hi Tim.

The solution I found was to set the Fixed Frame Length parameter to 1 on
the OFDM Frame Equalizer block of the "Header Stream".

The original value for this field is set to 0, but I don't exactly know
why
it works setting it to 1.

Regards.
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-09-26 07:10
(Received via mailing list)
On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
> The solution I found was to set the Fixed Frame Length parameter to 1 on the
> OFDM Frame Equalizer block of the "Header Stream".

Hi guys,

1 is the correct setting. I'm currently adding a tx into the example so
it runs as-is (like benchmark).

The reason: The headers have constant length, therefore it is not
necessary to propagate them as tagged streams. The way the header/paylod
demux work, it splits off the header and passes that regularly. There's
no need to generate a length tag.

MB


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
0d057c642b38689bfa090206eec844b8?d=identicon&s=25 Monahan-Mitchell, Tim (Guest)
on 2013-09-26 20:27
(Received via mailing list)
> On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
>> The solution I found was to set the Fixed Frame Length parameter to 1
>> on the OFDM Frame Equalizer block of the "Header Stream".

> 1 is the correct setting. I'm currently adding a tx into the example so it runs
as-is (like benchmark).

It would be interesting to keep the original diagram, and then also show
a replacement diagram that instead uses the OFDM Demod block and any
other newer ones that consolidate the equivalent function.

> The reason: The headers have constant length, therefore it is not necessary to
propagate them as tagged streams. The way the header/paylod demux work, it 
splits
off the header and passes that regularly. There's no need to generate a length
tag.

Maybe that explains why my earlier issue about the Length Tag Key value
for that same block does not matter (see GR issue # 593), since "1"
implies it is not needed.
0d057c642b38689bfa090206eec844b8?d=identicon&s=25 Monahan-Mitchell, Tim (Guest)
on 2013-09-26 22:00
(Received via mailing list)
>>> The solution I found was to set the Fixed Frame Length parameter to 1
>>> on the OFDM Frame Equalizer block of the "Header Stream".

>> 1 is the correct setting.

With this fix, now I see a new error:

INFO: Detected an invalid packet at item 0
INFO: Parser returned #f
thread[thread-per-block[18]: <block header_payload_demux (24)>]: Buffer
too small for min_noutput_items

I'll look into this, but just in case this is familiar to anyone...
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-09-27 07:56
(Received via mailing list)
On Thu, Sep 26, 2013 at 06:25:50PM +0000, Monahan-Mitchell, Tim wrote:
> > On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
> >> The solution I found was to set the Fixed Frame Length parameter to 1
> >> on the OFDM Frame Equalizer block of the "Header Stream".
>
> > 1 is the correct setting. I'm currently adding a tx into the example so it
runs as-is (like benchmark).
>
> It would be interesting to keep the original diagram, and then also show a
replacement diagram that instead uses the OFDM Demod block and any other newer
ones that consolidate the equivalent function.

Nothing's going to change with the original diagram. I'll just add an
ofdm_tx so it runs in loopback mode.

> > The reason: The headers have constant length, therefore it is not necessary to
propagate them as tagged streams. The way the header/paylod demux work, it 
splits
off the header and passes that regularly. There's no need to generate a length
tag.
>
> Maybe that explains why my earlier issue about the Length Tag Key value for that
same block does not matter (see GR issue # 593), since "1" implies it is not
needed.

Yep, exactly.


MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2013-11-07 00:29
(Received via mailing list)
> I'll look into this, but just in case this is familiar to anyone...
>

I face the same problem.

I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU
Radio reference GRC implementation), where the TX goes out to a USRP UHD
sink, and the RX reads from a USRP UHD source.

As long as the receive SNR is high enough, the problem does not show up.
However, as I gradually reduce the RX gain, at some point, the entire
thing
crashes with the "Buffer too small for min_noutput_items" error.

Any help would be greatly appreciated.

Aditya
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-11-07 13:58
(Received via mailing list)
On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote:
> I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio
> reference GRC implementation), where the TX goes out to a USRP UHD sink, and
> the RX reads from a USRP UHD source.
>
> As long as the receive SNR is high enough, the problem does not show up.
> However, as I gradually reduce the RX gain, at some point, the entire thing
> crashes with the "Buffer too small for min_noutput_items" error.

Are you using a current version? This problem was caused by bit errors
creating incorrect, but validated headers. In the current header, we
have an 8 Bit CRC check, which is pretty unlikely to cause this.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2013-11-07 16:01
(Received via mailing list)
On Thu, Nov 7, 2013 at 7:57 AM, Martin Braun (CEL)
<martin.braun@kit.edu>wrote:

> > crashes with the "Buffer too small for min_noutput_items" error.
>
> Are you using a current version? This problem was caused by bit errors
> creating incorrect, but validated headers. In the current header, we
> have an 8 Bit CRC check, which is pretty unlikely to cause this.
>

Hi Martin,

Thanks for your response.

Yes, I am using the current version pulled from the git sources.

To clarify, this is not a rare occurrence. With a > 50% probability,
when I
reduce the TX/RX gain, the problem shows up. The header/payload demux is
always the offending block.

Also, once this problem shows up, the entire RX path freezes up, and
needs
to be restarted.

Best,
Aditya
342253be268e47df9f93067e022c7e30?d=identicon&s=25 ashish mishra (Guest)
on 2013-11-07 16:14
(Received via mailing list)
Hi all,

 Martin, Aditya is correct I too am facing this issue with the new
rx_ofdm.grc. This error is prominent its only in some gain settings the
model works. Moreover in QPSK modulation CRC is rejecting nearly all the
packets.

Thanks,

Ashish



On Thursday, 7 November 2013 6:27 PM, Martin Braun (CEL)
<martin.braun@kit.edu> wrote:

On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote:

> I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio
> reference GRC implementation), where the TX goes out to a USRP UHD sink, and
> the RX reads from a USRP UHD source.
>
> As long as the receive SNR is high enough, the problem does not show up.
> However, as I gradually reduce the RX gain, at some point, the entire thing
> crashes with the "Buffer too small for min_noutput_items" error.

Are you using a current version? This problem was caused by bit errors
creating incorrect, but validated headers. In the current header, we
have an 8 Bit CRC check, which is pretty unlikely to cause this.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstrae 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Wrttemberg and
National Laboratory of the Helmholtz Association
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-11-12 18:44
(Received via mailing list)
On Thu, Nov 07, 2013 at 09:59:15AM -0500, Aditya Dhananjay wrote:
> Yes, I am using the current version pulled from the git sources.
>
> To clarify, this is not a rare occurrence. With a > 50% probability, when I
> reduce the TX/RX gain, the problem shows up. The header/payload demux is always
> the offending block.
>
> Also, once this problem shows up, the entire RX path freezes up, and needs to
> be restarted.

Hey guys,

and thanks again for testing this.

I ran some tests today and was able to reproduce this problem.

However, to make it happen, you have to severely screw up the OFDM
signal at the transmit side. The preamble detector (which is pretty
robust) will still detect packets, and then flood the header/payload
demuxer with guaranteed garbage. Eventually, even the 8-Bit CRC fails,
after rejecting lots of packets.

At this point, the HPD *should* catch the problem, but doesn't, which
causes the block_executor to throw a runtime_error. I'm not sure where
the bug is, but there definitely is one.

I've opened http://gnuradio.org/redmine/issues/611 and will try and
figure this out.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2013-11-12 19:56
(Received via mailing list)
>
>
> I've opened http://gnuradio.org/redmine/issues/611 and will try and
> figure this out.
>
Thanks, Martin.
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-15 21:28
(Received via mailing list)
>
>
>>
>> I've opened http://gnuradio.org/redmine/issues/611 and will try and
>> figure this out.
>
>
Hello Martin,

I am still facing a problem here. (I have pulled the newest sources from
GIT). First, let me describe the environment. I have connected the
transmitter side to a channel model that introduces frequency and timing
offsets (so that I have control over how dirty the channel is). From
this
channel model block, I feed it into the receiver blocks. I am not using
any
USRP or real hardware as of now.

Issue A: I notice that when the header CRC check fails, the entire
receive
path soon freezes up.

Issue B: Additionally, I notice that sometimes the header gets so
corrupted
that the CRC check passes (I suppose these false positives cannot be
helped, unless we have a longer CRC for the header, but that's probably
a
waste).

Issue A is the main problem for me. :)

Thank you!

Best regards,
Aditya
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-15 22:38
(Received via mailing list)
> Issue A: I notice that when the header CRC check fails, the entire receive
>
Dear All,

Please accept my sincere apologies.

Regarding issue A: The *payload* path freezes up, and this is the
expected
behavior since there are no valid headers that can be decoded. I had
erroneously stated that the *entire* receive path freezes up, which I
just
realized, is not the case.

Apologetically,
Aditya
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-16 01:58
(Received via mailing list)
Dear All,

There is a variant of this issue that I discovered and would like to
point
it out to the community.

Synopsis: After the first time the header CRC fails, *all* subsequent
packets fail.

Setup:

- GRC examples of Tx/Rx OFDM
- Noise source with a variable slider to control the amount of noise.
The
output of the Tx block is added with the output of the noise source.
- The output of this adder is connected to the Rx block.

Procedure:

- Start the experiment with 0 noise. We see that the packets are
successfully decoded.
- Increase the noise, and we observe that the packet success rate begins
to
drop (payload CRC failures)
- Further increase the noise to force a header CRC failure.
- Decrease the noise back to 0. Notice that the packet success rate
remains
0, even though the noise is 0.

This is highly repeatable. Any help would be greatly appreciated.

Best,
Aditya
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-01-16 16:13
(Received via mailing list)
On Wed, Jan 15, 2014 at 07:55:45PM -0500, Aditya Dhananjay wrote:
> output of the Tx block is added with the output of the noise source.
> 0, even though the noise is 0.
>
> This is highly repeatable. Any help would be greatly appreciated.

Hm, can't repeat it. I used the loopback example. Increasing noise does
make packets drop (as expected), but setting it back makes them come
again. A noise amplitude of ~2 causes most packets to fail, but some
come through. What are your OFDM specs?

MB
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-21 16:25
(Received via mailing list)
Thanks for trying, Martin.

My OFDM Specs are:

FFT size = 64
CP length = 16
bandwidth = 2KHz
carrier freq: centered around 2.437GHz

It is easier to reproduce if I replace the noise block with one that
adds
CFO errors.

a) Increase this CFO error until header CRCs fail. Let this stand for a
few
seconds.
b) Reduce CFO offset errors to 0.
c) Go to step a and repeat a few times.

I observe that after doing this a few times, the RX path freezes up.

In any case, thank you very much for trying to reproduce this error. I
really appreciate your help. :)

best regards,
aditya
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-01-21 18:19
(Received via mailing list)
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote:
> Thanks for trying, Martin.
>
> My OFDM Specs are:
>
> FFT size = 64
> CP length = 16
> bandwidth = 2KHz

Sure you don't mean 2 MHz? At this BW, I'm surprised if it worked at
all.

MB
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-21 18:25
(Received via mailing list)
Oops, that was a typo. Sorry. I meant 200KHz.
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-01-21 18:29
(Received via mailing list)
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote:
> Thanks for trying, Martin.
>
> My OFDM Specs are:
>
> FFT size = 64
> CP length = 16
> bandwidth = 2KHz
> carrier freq: centered around 2.437GHz

Do you see these only over-the-air, or only in simulation?

MB
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-01-21 18:32
(Received via mailing list)
On 01/15/2014 09:26 PM, Aditya Dhananjay wrote:
> Issue B: Additionally, I notice that sometimes the header gets so
> corrupted that the CRC check passes (I suppose these false positives
> cannot be helped, unless we have a longer CRC for the header, but that's
> probably a waste).

For the record: The default is 8 bits CRC, so there's a 1/256th chance a
packet will fail and pass. But then there's also the payload CRC, which
has 32 bits. Unlikely they'll both pass.

MB
3f8e1a4f07ff9f4f428055a3330aa26d?d=identicon&s=25 Aditya Dhananjay (Guest)
on 2014-01-21 18:43
(Received via mailing list)
>
>
>
>
> For the record: The default is 8 bits CRC, so there's a 1/256th chance a
> packet will fail and pass. But then there's also the payload CRC, which
> has 32 bits. Unlikely they'll both pass.
>

I agree. While false positives in the header CRC so happen from time to
time, I've never noticed a false positive with payload CRC.

best,
aditya
332b0ca9b755cd32b745eaf01c0c72e0?d=identicon&s=25 Johannes Demel (Guest)
on 2014-01-29 00:58
(Received via mailing list)
Hi,

The patch in 86845ea15ab8d36f5c196c8ab56e5b77d43b4cf9
did not make it into the 'maint' branch. As this is a bugfix it should
be
applied on this branch as well.

Happy hacking
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-01-29 13:00
(Received via mailing list)
On 29.01.2014 00:56, Johannes Demel wrote:
> Hi,
>
> The patch in 86845ea15ab8d36f5c196c8ab56e5b77d43b4cf9
> did not make it into the 'maint' branch. As this is a bugfix it should
> be applied on this branch as well.

This specific commit is in both maint and master. Sure you didn't mean
anything else?

MB
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.