[USRP-users] RuntimeError: Could not create nirio_zero_copy transport on X310

Martin Braun martin.braun at ettus.com
Thu Oct 29 16:00:30 EDT 2015


Marius,

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.

Cheers,
Martin

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
> faster.
> 
> If you send me your python program, I can suggest changes.
> 
> Thanks,
> Ashish
> 
> 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
>> (http://files.ettus.com/binaries/niusrprio/niusrprio-installer-15.0.0.tar.gz).
>> 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[3]: <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
>> moments.
>>
>> Thank you,
>> Marius
>>
>> On 21Oct 2015, at 20:02, Ashish Chaudhari <ashish.chaudhari at ettus.com>
>> wrote:
>>
>> 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.
>>
>> Best,
>>
>> 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:
>>>>
>>>> Hi,
>>>>
>>>> I get the fallowing error when I run my flowchart on the X310 USRP, :
>>>> thread[thread-per-block[3]: <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
>>>> -52005)
>>>>
>>>> My program initialises the time from the GPSDO with the fallowing
>>>> command:
>>>>
>>>> self.uhd_usrp_sink_0.set_time_next_pps(uhd.time_spec_t(self.uhd_usrp_sink_0.get_mboard_sensor("gps_time").to_int()
>>>> + 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.uhd_usrp_sink_0.set_start_time(uhd.time_spec_t(start_time))
>>>> #tb is the object, instance of the class top_block
>>>>        time_difference = int(start_time -
>>>> tb.uhd_usrp_sink_0.get_time_now().get_real_seconds())
>>>>        tb.start()
>>>>        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
>>>>        tb.stop()
>>>>        print “finished transmission at",
>>>> stringFromTime(tb.uhd_usrp_sink_0.get_time_now().get_real_seconds())
>>>>        tb.wait()
>>>>        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
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 





More information about the USRP-users mailing list