USRP1 4 Channel Subdev Issue

GNU Radio
1

Hello all,

I am trying to make the USRP1 work with 4 independent real signal
channels (not IQ) using two RX daughterboards. In the older versions of
GNURadio I was able to make this work with a custom block I had found in
a repository or from somebody on the mailing list.

I am using GRC to make scripts and in the newer UHD version I’m having
trouble making this work with 4 channels. I can make 2 channels work by
setting the Mb0:subdev specification in the UHD block to A:A A:B, or
even A:B B:B, etc.
When I try to make all four work by setting A:A A:B B:A B:B (four
independent real channels) I get the following error:

RuntimeError: ValueError: The subdevice specification “A:A A:B B:A B:B”
is too long.
The user specified 4 channels, but there are only 2 rx dsps on mboard 0.

Does anyone know how I can properly call the subdevice specification and
make this work without needing a custom block (I’m not skilled enough to
write complicated blocks)? Again, in the older GNURadio version I was
able to get 4 real RX channels to work independently with a custom block
someone else had written. I don’t think its compatible with the newer
UHD version as it was done in 2009.

Thank you, - Tom

2

or even A:B B:B, etc.
version I was able to get 4 real RX channels to work independently
with a custom block someone else had written. I don’t think its
compatible with the newer UHD version as it was done in 2009.

Thank you, - Tom

For 4 RX DSPs on the USRP1, you need the 4rx FPGA image:

http://files.ettus.com/uhd_docs/manual/html/usrp1.html#specify-a-non-standard-image

3

Oh ok I will try that out not sure why I didn’t come across that in my
search. Thanks so much Marcus!

-Tom

From: Marcus D. Leech [email protected]
To: [email protected]
Sent: Tuesday, February 19, 2013 11:13 AM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

Hello all,

RuntimeError: ValueError: The subdevice specification “A:A A:B B:A B:B” is too
long.
The user specified 4 channels, but there are only 2 rx dsps on
mboard 0.

Does anyone know how I can properly call the subdevice specification and make
this work without needing a custom block (I’m not skilled enough to write
complicated blocks)? Again, in the older GNURadio version I was able to get 4 real
RX channels to work independently with a custom block someone else had written. I
don’t think its compatible with the newer UHD version as it was done in 2009.

Thank you, - Tom

For 4 RX DSPs on the USRP1, you need the 4rx FPGA image:

http://files.ettus.com/uhd_docs/manual/html/usrp1.html#specify-a-non-standard-image

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

I tried the suggestion from Marcus and was able to get the USRP1 to work
with 4 real channels. I have a simple GRC script which samples the USRP
at 1MS/s and then resamples the signal to 500kS/s and then writes to a
file. I am getting continuous Overruns with this GRC script on my
laptop.

I have the same GRC script with the older GNURadio and when I ran it
again on the same laptop (I booted up a prior version of ubuntu with an
older gnuradio version that uses the USRP class not UHD) it writes to
file with no Overruns at all. I saw that the custom quad channel USRP
block has an fusb_block and fusb_nblocks setting. These are both set to
51232 but if I lower them to something like 6432 I start to see the
Overruns.

Are there similar type settings I can adjust on the 3.6.2 version of GRC
or GNURadio python scripts to get rid of the overruns? I’m not sure if
this is possible but I would like to not have to boot into an older
ubuntu version when I need 4 real channels. The only thing that comes to
mind is to adjust noutput_items and I tried this but it didn’t eliminate
the overruns.

Thank you, -Tom

From: Tom H. [email protected]
To: Marcus D. Leech [email protected]; “[email protected]”
[email protected]
Sent: Tuesday, February 19, 2013 11:19 AM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

Oh ok I will try that out not sure why I didn’t come across that in my
search. Thanks so much Marcus!

-Tom

From: Marcus D. Leech [email protected]
To: [email protected]
Sent: Tuesday, February 19, 2013 11:13 AM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

Hello all,

RuntimeError: ValueError: The subdevice specification “A:A A:B B:A B:B” is too
long.
The user specified 4 channels, but there are only 2 rx dsps on
mboard 0.

Does anyone know how I can properly call the subdevice specification and make
this work without needing a custom block (I’m not skilled enough to write
complicated blocks)? Again, in the older GNURadio version I was able to get 4 real
RX channels to work independently with a custom block someone else had written. I
don’t think its compatible with the newer UHD version as it was done in 2009.

Thank you, - Tom

For 4 RX DSPs on the USRP1, you need the 4rx FPGA image:

http://files.ettus.com/uhd_docs/manual/html/usrp1.html#specify-a-non-standard-image

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

5

USRP block has an fusb_block and fusb_nblocks setting. These are both
Thank you, -Tom

http://files.ettus.com/uhd_docs/manual/html/transport.html#usb-transport-libusb

The USB parameters shown there can be passed as device args

6

Thanks for the suggestion Marcus.

I tried adjusting those settings by using the following command:

uhd_usrp_probe --args=“serial=123456,
recv_frame_size=4096,num_recv_frames=4096”
The 123456 is replaced with the actual serial number of the usrp1 when I
run the command.

When I run that command it shows the USRP1 configuration settings and
the daughtercard and then at the bottom it says “Segmentation fault
(core dumped)”. This happens with other values of recv_frame_size and
num_recv_frames. Does anyone know what I’m doing wrong or is this even
the right way to change those settings?

What are the default values in case I need to set them back to what they
were? I couldn’t find this anywhere in the UHD documentation.

Thank you, - Tom

From: Marcus D. Leech [email protected]
To: Tom H. [email protected]
Cc: “[email protected]” [email protected]
Sent: Wednesday, February 20, 2013 9:53 AM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

I tried the suggestion from Marcus and was able to get the USRP1 to work
with 4 real channels. I have a simple GRC script which samples the USRP
at 1MS/s and then resamples the signal to 500kS/s and then writes to a
file. I am getting continuous Overruns with this GRC script on my
laptop.

I have the same GRC script with the older GNURadio and when I
ran it again on the same laptop (I booted up a prior version of
ubuntu with an older gnuradio version that uses the USRP class
not UHD) it writes to file with no Overruns at all. I saw that
the custom quad channel USRP block has an fusb_block and
fusb_nblocks setting. These are both set to 51232 but if I
lower them to something like 6432 I start to see the Overruns.

Are there similar type settings I can adjust on the 3.6.2
version of GRC or GNURadio python scripts to get rid of the
overruns? I’m not sure if this is possible but I would like to
not have to boot into an older ubuntu version when I need 4 real
channels. The only thing that comes to mind is to adjust
noutput_items and I tried this but it didn’t eliminate the
overruns.

Thank you, -Tom

http://files.ettus.com/uhd_docs/manual/html/transport.html#usb-transport-libusb

The USB parameters shown there can be passed as device args

7

On 02/20/2013 02:22 PM, Tom H. wrote:

What are the default values in case I need to set them back to what they were?
I couldn’t find this anywhere in the UHD documentation.

The values arent sticky, so you dont need to worry about that. The
default libusb xfer size if 16384 bytes.

I think the segfault comes from the number of frames. The default is 16,
and you can change this, but 4k is probably way more pending LUTs than
libusb can handle.

-josh

8

Thanks Josh.
I’ve tried some different combinations of uhd_usrp_probe
–args=“serial=123456, recv_frame_size=16384,num_recv_frames=16” and
varied recv_frame_size up to something really high like 1,000,000 and
num_recv_frames up to 400 and didn’t get the segementation fault error.

When I run my 4 channel RX script after trying some different
configurations I am still getting overruns. If I change the USRP
sampling rate to 500kS/s but leave the file rate at 500kS/s the overruns
go away however I want to sample the USRP at 1MS/s to have a flatter
frequency response. This leads me to think the Overruns are not caused
by the file writing part.

The fusb_block and fusb_nblocks setting were both set to 512*32 in the
older GNURadio version and custom USRP 4 channel source block. The same
script in the older GNURadio version still runs with no Overruns even at
1Ms/s for each of the 4 USRP channels.

Is there anything else I can try? Do I need to also alter the
send_frame_size and num_send_frames in the uhd_usrp_probe calls?

Thank you, Tom

From: Josh B. [email protected]
To: Tom H. [email protected]; “[email protected]”
[email protected]
Sent: Wednesday, February 20, 2013 4:34 PM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

On 02/20/2013 02:22 PM, Tom H. wrote:

What are the default values in case I need to set them back to what they were? I
couldn’t find this anywhere in the UHD documentation.

The values arent sticky, so you dont need to worry about that. The
default libusb xfer size if 16384 bytes.

I think the segfault comes from the number of frames. The default is 16,
and you can change this, but 4k is probably way more pending LUTs than
libusb can handle.

-josh

9

I forgot to mention that I had set three channels to null and kept just
one writing to a file. In this case I still see overruns.
Also if I drop the sampling rate to 500 MS/s on all four channels but
leave them all writing to file at 500 kS/s I don’t see any overruns at
all. The problem is I want 1 MS/s sampling for a flatter frequency
response.

Does anyone have advice on anything else I can try? Again in the older
version of GNURadio/GRC, I could run four channels at 1MS/s and write
all four to 500MS/s sampled files without any overruns at all.

Thank you, -Tom

From: Tom H. [email protected]
To: “[email protected]” [email protected]; “[email protected]”
[email protected]
Sent: Thursday, February 21, 2013 2:20 PM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

Thanks Josh.
I’ve tried some different combinations of uhd_usrp_probe
–args=“serial=123456, recv_frame_size=16384,num_recv_frames=16” and
varied recv_frame_size up to something really high like 1,000,000 and
num_recv_frames up to 400 and didn’t get the segementation fault error.

When I run my 4 channel RX script after trying some different
configurations I am still getting overruns. If I change the USRP
sampling rate to 500kS/s but leave the file rate at 500kS/s the overruns
go away however I want to sample the USRP at 1MS/s to have a flatter
frequency response. This leads me to think the Overruns are not caused
by the file writing part.

The fusb_block and fusb_nblocks setting were both set to 512*32 in the
older GNURadio version and custom USRP 4 channel source block. The same
script
in the older GNURadio version still runs with no Overruns even at 1Ms/s
for each of the 4 USRP channels.

Is there anything else I can try? Do I need to also alter the
send_frame_size and num_send_frames in the uhd_usrp_probe calls?

Thank you, Tom

From: Josh B. [email protected]
To: Tom H. [email protected]; “[email protected]”
[email protected]
Sent: Wednesday, February 20, 2013 4:34 PM
Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue

On 02/20/2013 02:22 PM, Tom H. wrote:

What are the default values in case I need to set them back to what they were? I
couldn’t find this anywhere in the UHD documentation.

The
values arent sticky, so you dont need to worry about that. The
default libusb xfer size if 16384 bytes.

I think the segfault comes from the number of frames. The default is 16,
and you can change this, but 4k is probably way more pending LUTs than
libusb can handle.

-josh

Thank you, - Tom

From: Marcus D. Leech [email protected]
To: Tom H. [email protected]
Cc: “[email protected]” [email protected]
Sent: Wednesday, February 20, 2013 9:53
AM
fusb_nblocks setting.
These are both set to 512*32 but if I