What probably would be even more insightful is if you could enable
ctrlport and add a ctrlport monitor to your flow graph; that way we
could see whether the output buffer of OFDM mapper is constantly
full.
On 31.03.2016 10:13, Marcus Müller
wrote:
Hi Abhinav,
On 31.03.2016 02:42, Abhinav Jadon
wrote:
I ran the volk_profile just after the
installation so that is not an issue i guess. Also, I played
around with the parameters of the message strobe ( the period
parameter), it did have an effect on the underruns and the
async message buffer overflow warning. Low values of the
period parameter prompted async message overflow warnings and
high values of the period parameter prompted underruns ( a lot
of them) .
Sooo, ok.
My head was stuck on UHD/the USRP being a problem here, but:
"asynchronous message buffer overflowing, dropping message"
is a GNU Radio warning!
So what happens here is that messages are sent to a block that's
not processing them fast enough, and at some point, the message
buffer just gets too big.
There's basically two candidates for this, because your message
passing chain is:
Message Strobe-> OFDM MAC->OFDM Mapper(->stream)
so my guess is that this happens at the OFDM Mapper, because that
is the block whose message processing rate is limited by the
amount of samples it can produce, which is defined by how fast the
USRP sink consumes those, in the end.
Quick test: Take the "Message Strobe -> OFDM MAC -> OFDM
Mapper" and just attach a "->Probe Rate->Message Debug".
How many items per second do your generate with the settings you
use when you get a lot of the "async mess. buff. overflow"
warnings?"
Best regards,
Marcus
What I dont understand is if the USRP is in the burst
mode, why does the period parameter change things ? If the
USRP is set to sample rate of 20e6, then it expects
period*sample_rate samples to be supplied to it. That
requires to change the length of the message again.
Whats wrong here ?
Regards
|