[USRP-users] UHD C++ API Questions

Michael West michael.west at ettus.com
Mon Dec 1 19:31:46 EST 2014


Answers inline:

On Mon, Dec 1, 2014 at 3:23 PM, Peter Witkowski via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hello,
>
> I am in the process of writing a simple RF receiving program that follows
> many of the same steps as rx_samples_to file.  I am following the example
> code found here:
> https://github.com/GREO/uhd/blob/master/host/examples/rx_samples_to_file.cpp
> .
>
> I had a couple questions come up as I was following the example:
>
> 1.  How are errors handled by the API?  For example, when I call uhd::usrp::multi_usrp::make()
> and it fails, how do I know that the pointer points to an invalid device?
> Do I check the pointer for null or is there an exception thrown?
>
The return value of make() is a shared_ptr.  You can do a simple check of
the validity of the shared pointer.  Assuming you use
"uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);",
you can simply add "if (not usrp) {}".

> 2.  Similar question to above, how do I know that device settings are
> actually set?  For example, for set_rx_rate() are any exceptions thrown
> if the rate is bad, or do I just need to call get_rx_rate() immediately
> afterwards?
>
I recommend doing the get_*() methods for sanity checks.

> 3.  In a newer version of rx_samples_to_file (see here:
> https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp
> ) I noticed that a tuning request is used to set the frequency of the
> device.  Is this the preferred method or does a call to set_rx_freq()
> suffice?
>
Either will work.  The tune request just gives you more control.

> 4.  In all the example code I've been able to dig up, the connection to
> the device is closed by simply exiting from the program.  Is there a way to
> close the device and perform the necessary clean-up (i.e. the opposite of
> make()) manually?
>
The necessary clean-up is done in the destructors, which are automatically
called when the program exits cleanly.  You can force the destructors to be
called by using "usrp.reset()".

> 5.  In the two versions of rx_samples_to_file that I found, I noted a
> difference in the way data is read from the device via recv().  Namely, I'm
> lost on the last two parameters that are passed in.  Do I have to specify
> an io_type and are there different options than RECV_MODE_FULL_BUFF?  Do I
> have to use a STL vector or can I pass it a different data structure (like
> a C-style buffer/array)?  I guess I just need to be pointed to a good few
> lines of code on how recv() works and is implemented.  Also, does recv()
> throw exceptions?
>
See the UHD API documentation for the information for the recv() call.
With UHD (and Boost), you have to learn to love templates. ;-)

Regards,
Michael E. West

>
> Thanks in advance for the help.
>
> --
> Peter Witkowski
> pwitkowski at gmail.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141201/fcada276/attachment-0002.html>


More information about the USRP-users mailing list