[USRP-users] UHD C++ API Questions

Marcus D. Leech mleech at ripnet.com
Tue Dec 2 13:12:22 EST 2014

> Finally, I just wanted to confirm that the UHD API does NOT throw 
> exceptions.  I guess I was used to lots of try-catch blocks in my code 
> due to working with other libraries.
Not sure where you got the impression that UHD, doesn't in general, 
throw exceptions.  Here's a list I produced with "find" and "grep" on 
the source


I think that the general error-handling strategy in UHD is to "carry on 
if possible", so if, for example, you try for a sample-rate that cannot 
be satisfied,
   it will program the hardware for the closest matching sample-rate.  
Similarly for frequency and gain changes.

But for others, such as asking for hardware that doesn't exist, there's 
no "closest match" possible, so it throws.

> Thanks again for the help.
> On Mon, Dec 1, 2014 at 7:31 PM, Michael West <michael.west at ettus.com 
> <mailto:michael.west at ettus.com>> wrote:
>     Answers inline:
>     On Mon, Dec 1, 2014 at 3:23 PM, Peter Witkowski via USRP-users
>     <usrp-users at lists.ettus.com <mailto: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 <mailto:pwitkowski at gmail.com>
>         _______________________________________________
>         USRP-users mailing list
>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -- 
> Peter Witkowski
> pwitkowski at gmail.com <mailto: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

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141202/785c42d5/attachment-0002.html>

More information about the USRP-users mailing list