How to deal with "underride"

GNU Radio
1

Dear all, I am wondering how to deal with “underride” of
usrp2. I am using simple-MAC of pre-cog. I replace
GMSK mod and demod block with PSK mod and demod in radio_hier.grc. Then
the terminal show “UUUUUUUU pkt failed arq” when every transmission.
My setting is gnuradio-3.6.2,USRP N210 Any advice is welcome.

=================================
Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

2

I compared the difference when using GMSK and PSK in simple_trx.grc
which use radio_hier.grc.When use GMSK, it callsgr_fir_fff: using SSE
When use PSK,it calls gr_fir_ccf: using SSEgr_fir_ccc: using SSE
Also I compare with benchmark_tx,when use PSKit calls gr_fir_ccf: using
SSE

when use gmskit callsgr_fir_fff: using SSE

I know c, f means different data type: complex and float.
Is it the reason why PSK fail to work? which calls additional
“gr_fir_ccc: using SSE”?
If it is not the reason, I will dive into framer, which may also cause
failure in TX.Thank you.

Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

From: [email protected]
To: [email protected]
Date: Mon, 10 Dec 2012 05:49:08 +0000
Subject: [Discuss-gnuradio] how to deal with “underride”

Dear all, I am wondering how to deal with “underride” of
usrp2. I am using simple-MAC of pre-cog. I replace
GMSK mod and demod block with PSK mod and demod in radio_hier.grc. Then
the terminal show “UUUUUUUU pkt failed arq” when every transmission.
My setting is gnuradio-3.6.2,USRP N210 Any advice is welcome.

=================================
Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

3

On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei [email protected]
wrote:

gr_fir_ccc: using SSE

Xiangwei Zheng

No, this is not the reason. This is probably a channel filter used in
PSK
signals and not in the GMSK signals.

Most likely the reason is frequency offset or too much or too little
power.

Tom

4

I think frequency offset may not be the reason.
The attachment is the oscilloscope picture. The first one use DBPSK
modulation, which can be received by simple_trx.py. The second one use
GMSK modulation, which can be successfully received by simple_trx.py.
I wonder is there any reason may cause simple_trx.py fail to work using
DBPSK.Thank you.

Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

From: [email protected]
Date: Wed, 12 Dec 2012 12:07:31 -0500
Subject: Re: [Discuss-gnuradio] how to deal with “underride”
To: [email protected]
CC: [email protected]

On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei [email protected]
wrote:

I compared the difference when using GMSK and PSK in simple_trx.grc
which use radio_hier.grc.When use GMSK, it callsgr_fir_fff: using SSE
When use PSK,

it calls gr_fir_ccf: using SSEgr_fir_ccc: using SSE
Also I compare with benchmark_tx,when use PSKit calls gr_fir_ccf: using
SSE

when use gmskit calls

gr_fir_fff: using SSE

I know c, f means different data type: complex and float.
Is it the reason why PSK fail to work? which calls additional
“gr_fir_ccc: using SSE”?

If it is not the reason, I will dive into framer, which may also cause
failure in TX.Thank you.

Xiangwei Zheng

No, this is not the reason. This is probably a channel filter used in
PSK signals and not in the GMSK signals.

Most likely the reason is frequency offset or too much or too little
power.
Tom

5

On Wed, Dec 12, 2012 at 6:20 PM, zhengxiangwei [email protected]
wrote:

=================================
Xiangwei Zheng

Neither of those figures really shows anything. The bandwidth is way too
high. But the fact that the scope is telling you that the signal is
clipping might be an indication that you’re feeding way too much power
into
the transmitter.

Tom

6

Hi, I think I make some progress. I think the problem are mainly
associated with “blob” used in simple_trx. I wonder except John
Malsbury, who write simple_trx in pre-cog, if there is anyone who can
fix the problem. The problem is to make simple_trx work with other
modulation in two host computers, like bpsk, QAM.

I compared radio block in simple_trx and benchmark_tx and benchmark_rx.
Radio_hier of simple_trx can be seen in
https://github.com/buoyboy/pre-cog/wiki/A-Simple-Packet-Radio-Example.

I find in the receive path, they are same, except in simple_trx,
gr_msg_queue() is set to gr_msg_queue(4) and in benchmark, it is
default. The detail of receive path
is"uhd_source->channel_filter->demodulator->correlator->frame_sink"demodulator,
and correlator are modules in gr-digital.
But in transmitter path, there is a big difference.In
simple_trx,“pad_source->framer->modulator->muliplier->burst_gate->uhd_sink”
In benchmark"pkt_input->modulator->amplifier->uhd_sink
From the codes of framer and burst_gate, I do not really understand how
they works. But
But after I change the transmitter path of simple_trx,(remove framer and
burst_gate) it can receive some data from radio, but the data type is
not righ, so the recieve host print its address “86” and data receive
and “not a blob --simple MAC”.
But if I keep them, then modulator fails for DBPSK, but it works for
GMSK. It is really strange after changing the modulation, then
simple_trx fails to work.
There is some link describe pmt_blob. But I am not sure the advantage of
using blob and where blob is
defined.Home · guruofquality/grextras Wiki · GitHub

Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

From: [email protected]
Date: Thu, 13 Dec 2012 11:16:01 -0500
Subject: Re: [Discuss-gnuradio] how to deal with “underride”
To: [email protected]
CC: [email protected]

On Wed, Dec 12, 2012 at 6:20 PM, zhengxiangwei [email protected]
wrote:

I think frequency offset may not be the reason.
The attachment is the oscilloscope picture. The first one use DBPSK
modulation, which can be received by simple_trx.py. The second one use
GMSK modulation, which can be successfully received by simple_trx.py.

I wonder is there any reason may cause simple_trx.py fail to work using
DBPSK.Thank you.

=================================
Xiangwei Zheng
Neither of those figures really shows anything. The bandwidth is way too
high. But the fact that the scope is telling you that the signal is
clipping might be an indication that you’re feeding way too much power
into the transmitter.

Tom

From: [email protected]
Date: Wed, 12 Dec 2012 12:07:31 -0500

Subject: Re: [Discuss-gnuradio] how to deal with “underride”
To: [email protected]
CC: [email protected]

On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei [email protected]
wrote:

I compared the difference when using GMSK and PSK in simple_trx.grc
which use radio_hier.grc.When use GMSK, it callsgr_fir_fff: using SSE
When use PSK,

it calls gr_fir_ccf: using SSEgr_fir_ccc: using SSE
Also I compare with benchmark_tx,when use PSKit calls gr_fir_ccf: using
SSE

when use gmskit calls

gr_fir_fff: using SSE

I know c, f means different data type: complex and float.
Is it the reason why PSK fail to work? which calls additional
“gr_fir_ccc: using SSE”?

If it is not the reason, I will dive into framer, which may also cause
failure in TX.Thank you.

Xiangwei Zheng

No, this is not the reason. This is probably a channel filter used in
PSK signals and not in the GMSK signals.

Most likely the reason is frequency offset or too much or too little
power.
Tom

7

A blob is essentially a pointer with a byte count, and is used to move
raw
data around with messages.

The burst gate was a band-aid that was used to move the “tx_eob” tag to
the
last sample, since this is not assured in the way GNU Radio propogates
tags
across interpolating blocks like modulators. It makes a pretty large
assumption that all of the samples of a burst are present in the input
buffer, which may not always be true - when you change to different
modulator for example.

Can you send your flowgraphs so I can see what you are doing when you
modify simple_trx? It’s unclear to me how you would receive the message
you mentioned below if you’ve removed the framer all together.

-John

8

Thank you for your reply.
The first attachment “radio_hier_dpsk_benchmark” corresponds to the
screenshot of last e-mail. I only change the radio_hier.block to
benchmark
tx_path and rx_path. It seems then demod is successful. Mac layer can
receive data but not in blob type.

The second attachment “radio_hier_dpsk” is the one I want to make it
work.
I only change the mod and demod block compared with original
“raido_hier”,
which use GMSK.

I wonder is radio_hier support other modulation? Anyone succeed before?
Can
you send me the block if it is convenient.

The third attachment is another thing I am working. Because use socket
the
transmit is not continues, I try to replace it with file_source and
file_sink. However, after I make a change, it do not get or send any
data
from the file.

Also, I am planning to implement simple_trx via TDMA on three computers.
But I find there is no example or description how to use TDMA block in
pre-cog. I wonder if there is such grc files, I can refer.
Thank you very much again for your reply.
I have been bothered for this thing for days.

=================================
Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

Date: Thu, 13 Dec 2012 15:03:07 -0800
Subject: Re: [Discuss-gnuradio] how to deal with “underride”
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]

A blob is essentially a pointer with a byte count, and is used to move
raw
data around with messages.

The burst gate was a band-aid that was used to move the “tx_eob” tag to
the
last sample, since this is not assured in the way GNU Radio propogates
tags
across interpolating blocks like modulators. It makes a pretty large
assumption that all of the samples of a burst are present in the input
buffer, which may not always be true - when you change to different
modulator for example.

Can you send your flowgraphs so I can see what you are doing when you
modify simple_trx? It’s unclear to me how you would receive the message
you mentioned below if you’ve removed the framer all together.

-John

On Thu, Dec 13, 2012 at 1:35 PM, zhengxiangwei [email protected]
wrote:

Hi,
I think I make some progress. I think the problem are mainly
associated with “blob” used in simple_trx. I wonder except John
Malsbury,
who write simple_trx in pre-cog, if there is anyone who can fix the
problem. The problem is to make simple_trx work with other modulation in
two host computers, like bpsk, QAM.

I compared radio block in simple_trx and benchmark_tx and benchmark_rx.
Radio_hier of simple_trx can be seen in
https://github.com/buoyboy/pre-cog/wiki/A-Simple-Packet-Radio-Example.

I find in the receive path, they are same, except in simple_trx,
gr_msg_queue() is set to gr_msg_queue(4) and in benchmark, it is
default.
The detail of receive path is
“uhd_source->channel_filter->demodulator->correlator->frame_sink”
demodulator, and correlator are modules in gr-digital.

But in transmitter path, there is a big difference.
In simple_trx,
“pad_source->framer->modulator->muliplier->burst_gate->uhd_sink”

In benchmark
"pkt_input->modulator->amplifier->uhd_sink

From the codes of framer and burst_gate, I do not really understand how
they works. But

But after I change the transmitter path of simple_trx,(remove framer and
burst_gate) it can receive some data from radio, but the data type is
not
righ, so the recieve host print its address “86” and data receive and
“not
a blob --simple MAC”.

But if I keep them, then modulator fails for DBPSK, but it works for
GMSK. It
is really strange after changing the modulation, then simple_trx fails
to
work.

There is some link describe pmt_blob. But I am not sure the advantage of
using blob and where blob is defined.

=================================
Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

From: [email protected]
Date: Thu, 13 Dec 2012 11:16:01 -0500

Subject: Re: [Discuss-gnuradio] how to deal with “underride”
To: [email protected]
CC: [email protected]

On Wed, Dec 12, 2012 at 6:20 PM, zhengxiangwei [email protected]
wrote:

I think frequency offset may not be the reason.

The attachment is the oscilloscope picture. The first one use DBPSK
modulation, which can be received by simple_trx.py. The second one use
GMSK
modulation, which can be successfully received by simple_trx.py.

I wonder is there any reason may cause simple_trx.py fail to work using
DBPSK.
Thank you.

=================================
Xiangwei Zheng

Neither of those figures really shows anything. The bandwidth is way too
high. But the fact that the scope is telling you that the signal is
clipping might be an indication that you’re feeding way too much power
into
the transmitter.

Tom

From: [email protected]
Date: Wed, 12 Dec 2012 12:07:31 -0500
Subject: Re: [Discuss-gnuradio] how to deal with “underride”
To: [email protected]
CC: [email protected]

On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei [email protected]
wrote:

I compared the difference when using GMSK and PSK in simple_trx.grc
which
use radio_hier.grc.
When use GMSK,
it calls
gr_fir_fff: using SSE

When use PSK,
it calls
gr_fir_ccf: using SSE
gr_fir_ccc: using SSE

Also I compare with benchmark_tx,
when use PSK
it calls gr_fir_ccf: using SSE

when use gmsk
it calls
gr_fir_fff: using SSE

I know c, f means different data type: complex and float.

Is it the reason why PSK fail to work? which calls additional
“gr_fir_ccc:
using SSE”?

If it is not the reason, I will dive into framer, which may also cause
failure in TX.
Thank you.

=================================
Xiangwei Zheng

No, this is not the reason. This is probably a channel filter used in
PSK
signals and not in the GMSK signals.

Most likely the reason is frequency offset or too much or too little
power.

Tom