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.
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 B.
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
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.
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…
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
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 B.
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
On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya D. 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 B.
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
On Thu, Nov 7, 2013 at 7:57 AM, Martin B. (CEL)
[email protected]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
On Thu, Nov 07, 2013 at 09:59:15AM -0500, Aditya D. 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 B.
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
I’ve opened http://gnuradio.org/redmine/issues/611 and will try and
figure this out.
Thanks, Martin.
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 B. (CEL)
[email protected] wrote:
On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya D. 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 B.
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
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
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
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
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
On Wed, Jan 15, 2014 at 07:55:45PM -0500, Aditya D. 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
On 01/21/2014 04:23 PM, Aditya D. 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
Oops, that was a typo. Sorry. I meant 200KHz.
On 01/15/2014 09:26 PM, Aditya D. 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
On 01/21/2014 04:23 PM, Aditya D. 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