Dear USRP-Users,

I wanted to get back to you on the topic mentioned below. Meanwhile I reworked my code to work directly with the uhd Python class instead of using a gnuradio wrapper.

Unfortunately I run into the identical issue again.

Code is:

import uhd
import numpy as np

device = uhd.usrp.MultiUSRP(“type=x300,addr=192.168.40.2”)

for i in range(200):
sig = device.recv_num_samps(int(1e5),900e6,4e6,[0],0)
print(np.mean(sig))

<<

It’ll crash after 104 runs in file multi_usrp.py on line 54:

super(MultiUSRP, self).set_rx_gain(gain,chan)
<<

with the message mentioned below

RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer
<<

Anybody got an idea, if this might be some known issue with e.g. the FPGA code, or the drivers?

Best regards
Christoph

Christoph Schultz
RF System Architect

[RIEDEL at Social Media]https://www.riedel.net/en/social-media-links/

RIEDEL
Communications GmbH & Co. KG
Uellendahler Str. 353
42109 Wuppertal
Deutschland

phone: +49 202 292-9150

Christoph.Schultz@riedel.netmailto:Christoph.Schultz@riedel.net
www.riedel.nethttp://www.riedel.net

RIEDEL Communications GmbH & Co. KG
Registergericht: Amtsgericht Wuppertal HRA 22390
Umsatzsteuer-Identifikationsnummer: DE 814906984
Komplementärin: RIEDEL Communications International GmbH, Wuppertal
Registergericht: Amtsgericht Wuppertal HRB 17038
Geschäftsführer: Thomas Riedel, Frank Eischet, Martin Berger

From: Christoph Schultz (Riedel) Christoph.Schultz@riedel.net
Sent: Donnerstag, 25. November 2021 17:08
To: usrp-users@lists.ettus.com
Subject: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer

Dear USRP-Users,

I am facing a crash when repeatedly receiving data on a X300 using Gnuradio.
To run into this issue, I load a top_block with a usrp_source, a head and a file_sink initially.
Then a sequence of start()-wait()-stop()-wait()-reconfigure is run for e.g. 200 times.

After a deterministic number of cycles the following error will appear:

thread[thread-per-block[0] <block usrp_source(1)>]: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer
Similar to the issue discussed here:
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11413.html
my first idea was, that the command buffer is getting filled faster than it is sent to the USRP device, but artificial sleeps between the loop cycles do not change the behavior at all.

I was also not successful in reloading the usrp_source object on Python level (without stopping the full python process, and restarting it again manually).

So it looks like the gnuradio functions leave something in the command buffer which I couldn’t clear so far without reloading the whole library by restarting Python.

Is this a known issue? Are there any ways to manually release the command buffer, or is it a potential bug, which should go to the bug tracker of gr?

Many thanks in advance and
Best regards
Christoph

On 2021-12-06 02:13, Christoph Schultz (Riedel) wrote:

What is it you're trying to achieve?    The approach you're taking is
clearly exercising a deficiency in the UHD code somewhere, and perhaps
a different
  approach is required.

The normal "pattern" is:

     o set up device parameters
     o iterate getting data until satisfied

But I think the call you're using basically does a lot of "set up device
parameters" work every time you call it, which is not the usual "pattern".

Thanks for clarification!
I would like to do a frequency sweep, and would therefore like to use the following sequence:

• Initialize Device
• Repeat n times:
• Setup device to fn
• Measure

I finally managed to circumvent the described issue, by shifting the “Initialize device” step inside the loop:

• Repeat n times:
• (Re-)Initialize Device every m-th iteration
• Setup device to fn
• Measure

With Gnuradio this was not possible.

Btw – is there a better approach to do a frequency sweep that avoids setting up the device parameters over and over again?

Best regards
Christoph

Christoph Schultz
RF System Architect

[RIEDEL at Social Media]https://www.riedel.net/en/social-media-links/

RIEDEL
Communications GmbH & Co. KG
Uellendahler Str. 353
42109 Wuppertal
Deutschland

phone: +49 202 292-9150

Christoph.Schultz@riedel.netmailto:Christoph.Schultz@riedel.net
www.riedel.nethttp://www.riedel.net

RIEDEL Communications GmbH & Co. KG
Registergericht: Amtsgericht Wuppertal HRA 22390
Umsatzsteuer-Identifikationsnummer: DE 814906984
Komplementärin: RIEDEL Communications International GmbH, Wuppertal
Registergericht: Amtsgericht Wuppertal HRB 17038
Geschäftsführer: Thomas Riedel, Frank Eischet, Martin Berger

From: Marcus D. Leech patchvonbraun@gmail.com
Sent: Montag, 6. Dezember 2021 15:15
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer

WARNING: External E-Mail! Be cautious with logins, attachments and links! WARNUNG: Externe E-Mail! Achtung bei Logins, Anlagen und Links!

On 2021-12-06 02:13, Christoph Schultz (Riedel) wrote:
Dear USRP-Users,

I wanted to get back to you on the topic mentioned below. Meanwhile I reworked my code to work directly with the uhd Python class instead of using a gnuradio wrapper.

Unfortunately I run into the identical issue again.
What is it you're trying to achieve?    The approach you're taking is clearly exercising a deficiency in the UHD code somewhere, and perhaps a different
approach is required.

The normal "pattern" is:

 o set up device parameters
 o iterate getting data until satisfied

But I think the call you're using basically does a lot of "set up device parameters" work every time you call it, which is not the usual "pattern".

Code is:

import uhd
import numpy as np

device = uhd.usrp.MultiUSRP(“type=x300,addr=192.168.40.2”)

for i in range(200):
sig = device.recv_num_samps(int(1e5),900e6,4e6,[0],0)
print(np.mean(sig))

<<

It’ll crash after 104 runs in file multi_usrp.py on line 54:

super(MultiUSRP, self).set_rx_gain(gain,chan)
<<

with the message mentioned below

RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer
<<

Anybody got an idea, if this might be some known issue with e.g. the FPGA code, or the drivers?

Best regards
Christoph

Christoph Schultz
RF System Architect

[RIEDEL at                        Social Media]https://www.riedel.net/en/social-media-links/

RIEDEL
Communications GmbH & Co. KG
Uellendahler Str. 353
42109 Wuppertal
Deutschland

phone: +49 202 292-9150

Christoph.Schultz@riedel.netmailto:Christoph.Schultz@riedel.net
www.riedel.nethttp://www.riedel.net

RIEDEL Communications GmbH & Co. KG
Registergericht: Amtsgericht Wuppertal HRA 22390
Umsatzsteuer-Identifikationsnummer: DE 814906984
Komplementärin: RIEDEL Communications International GmbH, Wuppertal
Registergericht: Amtsgericht Wuppertal HRB 17038
Geschäftsführer: Thomas Riedel, Frank Eischet, Martin Berger
From: Christoph Schultz (Riedel) Christoph.Schultz@riedel.netmailto:Christoph.Schultz@riedel.net
Sent: Donnerstag, 25. November 2021 17:08
To: usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Subject: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer

Dear USRP-Users,

I am facing a crash when repeatedly receiving data on a X300 using Gnuradio.
To run into this issue, I load a top_block with a usrp_source, a head and a file_sink initially.
Then a sequence of start()-wait()-stop()-wait()-reconfigure is run for e.g. 200 times.

After a deterministic number of cycles the following error will appear:

thread[thread-per-block[0] <block usrp_source(1)>]: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer
Similar to the issue discussed here:
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11413.html
my first idea was, that the command buffer is getting filled faster than it is sent to the USRP device, but artificial sleeps between the loop cycles do not change the behavior at all.

I was also not successful in reloading the usrp_source object on Python level (without stopping the full python process, and restarting it again manually).

So it looks like the gnuradio functions leave something in the command buffer which I couldn’t clear so far without reloading the whole library by restarting Python.

Is this a known issue? Are there any ways to manually release the command buffer, or is it a potential bug, which should go to the bug tracker of gr?

Many thanks in advance and
Best regards
Christoph

USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com

To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com

On 2021-12-06 09:38, Christoph Schultz (Riedel) wrote:

In GR, you'd just change the frequency on the UHD source block whenever
you wanted a new frequency.   The samples are tagged, so you can
determine in the
  sample-stream when the frequency has changed.  No teardown/setup
required, and you sure as heck don't have to stop/reconfigure/start.

Managing the frequency schedule can be done in a number of ways.

But the detailed discussion of how to manage GR flows probably belongs
on the discuss-gnuradio list.