[USRP-users] RuntimeError: Could not create nirio_zero_copy transport on X310
martin.braun at ettus.com
Thu Oct 29 16:00:30 EDT 2015
are you familiar with stream tags and tagged streams? I think they will
take care of most of what you need. You create a tagged stream (this
will be tx'd as a burst) and you can add a tx time to identify when
it'll be tx'd.
On 28.10.2015 15:14, Ashish Chaudhari via USRP-users wrote:
> Hi Marius,
> Thanks for the update. The additional error does confirm my suspicion
> that starting and stopping streams in UHD seems to be leaking
> references. In general our recommendation is to try not to recreate
> streamer objects (UHD sinks and sources) to send/receive repeated
> bursts. Starting and stopping the top_block effectively does that. You
> should be able to initialize a UHD source/sink in a top block once and
> then call recv/send on it repeatedly. Not only is that stable but also
> If you send me your python program, I can suggest changes.
> On Wed, Oct 28, 2015 at 11:23 AM, Marius <metallheart_18 at yahoo.com> wrote:
>> Hi Ashish,
>> Thank you for looking into the problem.
>> I want to give you another updated. In despair to resolve the problem, I
>> updated my niusrprio driver to the latest version
>> Previous I had a version from 2014.
>> Now, at the same moment (at the second iteration of the wild loop) I
>> sometimes get the some error and other times I get this error:
>> thread[thread-per-block: <block gr uhd usrp sink (1)>]: RuntimeError:
>> Could not create nirio_zero_copy transport. A Configure FIFO, Stop FIFO,
>> Read FIFO, or Write FIFO function was called while the host had acquired
>> elements of the FIFO. Release all acquired elements before configuring,
>> stopping, reading, or writing. (Error code -63083)
>> I don’t know if this will help to pin-down the problem.
>> Also, if you want, I can send you the entire python program or the output of
>> the uhd_usrp_probe.
>> Please keep me up to date with the status of the issue, because if it can’t
>> be fixed I want to try other ways to start and end the emitter a fixed GPS
>> Thank you,
>> On 21Oct 2015, at 20:02, Ashish Chaudhari <ashish.chaudhari at ettus.com>
>> Hi Marius,
>> Thanks for the additional information. We are looking into this right now.
>> We will let you know as soon as we have updates.
>> Ashish Chaudhari | Senior Software Engineer | Software Defined Radio
>> Ettus Research, A National Instruments Company
>> ashish.chaudhari at ettus.com
>> On Wed, Oct 21, 2015 at 9:53 AM, Marius via USRP-users
>> <usrp-users at lists.ettus.com> wrote:
>>> Could not figure out the source of the problem.
>>> I could only traceback the issue that the error is outputted when the
>>> tb.start() is issued. More interesting is that then I use the same algorithm
>>> for receiving it works without a problem.
>>> I guess is probably a bug for the X310.
>>>> On 20Oct 2015, at 17:11, Marius <metallheart_18 at yahoo.com> wrote:
>>>> I get the fallowing error when I run my flowchart on the X310 USRP, :
>>>> thread[thread-per-block: <block gr uhd usrp sink (1)>]: RuntimeError:
>>>> Could not create nirio_zero_copy transport. A parameter to a function was
>>>> not valid. This could be a NULL pointer, a bad value, etc. (Error code
>>>> My program initialises the time from the GPSDO with the fallowing
>>>> + 1))
>>>> and then starts transmitting and certain moments between a start time
>>>> and a stop time. For that I use the fallowing algorithm:
>>>> while start_time < stopTime:
>>>> #tb is the object, instance of the class top_block
>>>> time_difference = int(start_time -
>>>> print “the transmission will start at",
>>>> stringFromTime(start_time) #stringFromTime is a function that
>>>> converts timestamps in date.time
>>>> time.sleep(time_difference + active_time) #active_time is the
>>>> duration of the transmission
>>>> print “finished transmission at",
>>>> start_time = int(tb.get_current_time() + wait_time) + 1
>>>> # wait_time is the duration between two transmissions
>>>> The error is outputted after the first transmission starts, and then
>>>> repeated after every iteration in the while loop, but the signal is
>>>> outputted only once.
>>>> The same code runs perfectly on USRP N210.
>>>> I use the latest uhd version 003.010.git-65-g9117fdc9 with LFTX
>>>> daughterboard and i use PCIe to connect to the USRP. The error was also
>>>> present at previous uhd version 3.8.4
>>>> Do you have any idea what is wrong?
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
More information about the USRP-users