[USRP-users] UHD C++ API Questions

Marcus D. Leech mleech at ripnet.com
Tue Dec 2 13:49:26 EST 2014


On 12/02/2014 01:28 PM, Peter Witkowski via USRP-users wrote:
> Where can I find a list or know whether or not a function throws an 
> exception or not?  I've spent some time now looking through the 
> Doxygen documentation that's available and am still, very much lost.  
> It would be nice to know how errors are handled so that I can deal 
> with them accordingly.
>
> In my original question, I asked to see how I can check for errors for 
> functions to configure the device using the "set" functions in 
> multi_usrp.  The response I got indicated that it's best to check the 
> value with the corresponding "get" function.  This led me to invalidly 
> assume that these functions don't throw exceptions.
Unfortunately, the Doxygen documentation doesn't capture that 
information, but I agree that information should be captured in the API
   documentation.

>
> So my new question is what functions do throw exceptions, so that I 
> can check for this case instead of just having my program exit due to 
> the unhandled exception?
>
> Also, once I call make() on a multi_usrp and issue a stream command to 
> it to start streaming how do I clean up?  There is no reset() for 
> multi_usrp that I've been able to find.  What does the shared pointer 
> point to once this clean up is finished?  Finally, it appears that I 
> am using a deprecated function for set_rx_freq since I am able to 
> simply pass in a double for the frequency.
I shall defer the destructor-architecture question to Michael West, 
because I note that ~multi_usrp() is defined as  NOP function.  So I'm 
not sure
   how all this gets cleaned up, to be honest.

With respect to your set_rx_freq question, tune_request_t is polymorphic 
(is that the right C++ jargon?  I'm not a C++ guy in any kind of
   full-time capacity):

http://files.ettus.com/manual/structuhd_1_1tune__request__t.html

Which means that passing in a straight double is a simple tuning request 
without any fancy offset tuning.



>
> On Tue, Dec 2, 2014 at 1:12 PM, Marcus D. Leech via USRP-users 
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>
>
>>
>>     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
>       tree:
>
>     http://www.sbrac.org/files/uhd_exceptions.txt
>
>     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  <mailto: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
>     http://www.sbrac.org
>
>
>     _______________________________________________
>     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
http://www.sbrac.org

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


More information about the USRP-users mailing list