From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

Can niusrp.dll provide access to other messages in RX stream?

I've been using niusrp.dll to control an Ettus N210, and that's been fine for the RX streaming that I've needed.  However, I now want to experiment with some features that don't appear to be supported by the niUSRP DLL.  Specifically, I've learned of an FPGA image that can send asynchronous timestamp messages upon a GPIO pin state change. Is there any way to use the niUSRP DLL to get those messages?

 

I've begun looking at what it would take to use the UHD driver DLL instead of the niUSRP DLL, but I'm discouraged by the complexity of the UHD driver and all of the dependencies and build requirements necessary to use the UHD driver, especially in my environment of MSVC under Windows.  In addition, the UHD driver appears to lack high-level documentation equivalent to the easy-to-understand APIs described in the niUSRP.h include file.

 

Are there any plans to add support in niUSRP.dll for alternate message types in the RX stream?

 

Thanks.

 

 

0 Kudos
Message 1 of 4
(6,152 Views)

In the interest of stable behavior, the NI-USRP driver does not support custom builds of the FPGA.

 

If you provide more details about what you're trying to accomplish, we may be able to suggest alternative solutions that keep you using the NI-USRP API.

0 Kudos
Message 2 of 4
(6,149 Views)

My application requires me to precisely align external asynchronous real-time events that affect the RF signal to algorithms applied the receiver IQ data.  The choice of algorithm depends on system state that can be inferred by GPIO signal transitions.  Therefore, when I learned that I could use a custom FPGA build to insert time-tagged messages based on GPIO pin changes, I realized that could solve my problem because the timetags from the GPIO messages can be correlated with the timetags of the receiver metadata.

 

It is my understanding (I could be wrong) that the Ettus N210 UDP transmissions follow the VITA-49 specification, aka VITA Radio Transport (VRT).  That specification has support for intermixing various kinds of logical streams into the one physical stream.  One logical stream sends the receiver IQ data, but other streams can be present.  Those other logical streams is where I believe the GPIO timetagged messages would manifest (again... I could be wrong). 

 

Without knowing the internal architecture of the niUSRP driver, I can only guess that it may have a packet processor that captures the receiver IQ stream packets, and discards all other packets.  If this guess is correct, the niUSRP API could provide a hook whereby an application such as mine could get be handed the discarded packets.  I could write my own code to process the packets of interest to my application.  An approach like this isn't specifically related to custom FPGA builds, but rather related to the VITA specification in general.  In that light, I believe that such a modification to niUSRP could be a feature of general interest to all USRP users, not just me.

 

Are there any plans to extend the niUSRP API in any way, or to release the driver source code under an open license?

 

Thanks,

Ed Jubenville

0 Kudos
Message 3 of 4
(6,141 Views)

Hi Ed,

 

There aren't any plans to expose the source code for the niUSRP.dll or it's api. Some of the functionality that you describe is actually handled by the UHD driver (the buffering / arbitration of packets). Much of the niUSRP driver consists of LabVIEW interface specific code, for instance allowcate memory safely for LabVIEW, to populate the IVI control / indicator and maintain a state between calls, and more. As mentioned above it's also tied to a specific version of the USRP FPGA image and firmware that ship with the driver. My recommendation would be to re-examine the UHD driver--it's possible to put a more simple wrapper around it that may suit your needs.

 

I hope that this helps,

 

--Sam

Sam Shearman
0 Kudos
Message 4 of 4
(6,136 Views)