[USRP-users] UHD C++ API Questions

Peter Witkowski pwitkowski at gmail.com
Tue Dec 2 12:06:33 EST 2014


I appreciate the responses so far.  However, I'm still a bit lost.

So if any one of the set functions get passed garbage, what happens?  Say I
do usrp->set_rx_subdev_spec("GARBAGE").  When I call get_rx_subdev_spec(),
what is the value returned?  That is, does set_rx_subdev_spec set the value
to "GARBAGE" or does it ignore invalid inputs?  If the invalid input is in
fact set, does an error get thrown when usrp->issue_stream_cmd() is
called?  Basically, I'm wondering if I need to call a "get" function every
time I call a "set" function or if I can wait until issue_stream_cmd() for
any errors to get sent back.  Speaking of which, how does
issue_stream_cmd() send back errors in the case where the device is not
streaming for some reason?

Also, say I use make() and now have a valid shared pointer pointing to the
device.  I now do an issue_stream_cmd() to start streaming and continuously
do recv() to pull in data.  I now want to manually clean-up and close the
connection to the device.  If I call ursp->reset() does streaming
automatically stop and is the device now in the same state as it was when
it was powered on?  What does usrp point to now (NULL or a valid device
that is reset)?  What happens if I call make() again after reset()?

Another point where I'm still lost is for recv(), how do I do a simple,
non-blocking read (i.e., what do I set the last parameter to)?  I want to
continuously poll the device to give me the samples it currently has stored
in order to prevent overflows (i.e., I don't want to wait for the vector
I've passed in to be filled).  Also, based on the two different versions of
rx_samples_to_file, the versions for recv() are a little different.  Are
there different versions of recv() in the API (the rx_streamer version
looks like it has a different function prototype)?  Which one would be
easiest to do a non-blocking read with?

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.

Thanks again for the help.


On Mon, Dec 1, 2014 at 7:31 PM, Michael West <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> 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
>>
>>
>


-- 
Peter Witkowski
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141202/f799be37/attachment-0002.html>


More information about the USRP-users mailing list