Hi Ofer,
The mb_controller class is a UHD 4.0 addition.  Are you using UHD 4.0 or
3.15?  If using UHD 4.0 you can get access to the mb_controller through the
get_mb_controller() function of any rfnoc block or the graph.  If using UHD
3.15, you likely need to access via the tree as Marcus said. I see that in
my 3.15 code, I had the following function.

uhd::sensor_value_t get_mboard_sensor(const std::string &name, size_t mboard)
override
{
return _tree->access<uhd::sensor_value_t>(mb_root(mboard) / "sensors" / name
).get();
}

On Tue, Feb 16, 2021 at 3:16 PM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear Ofer,
>
> You're right, the get_mboard_sensor is a property of the multi_usrp class
> and logically
> doesn't "map" to the device3 class.
>
> I don't have an ultimately good solution, here, to be honest. As a ugly
> yet functional
> workaround:
>
>     auto sensor_values =
> my_device3_sptr->get_tree()->access<uhd::sensor_value_t>(path).get();
>
> where "path" is the path to your sensor value. To find that, try
> `uhd_usrp_probe --tree |
> grep sensors`.
>
> Best regards,
>
> Marcus
>
> DISCLAIMER: Any attached Code is provided As Is. It has not been tested or
> validated as a product, for use in a deployed application or system, or for
> use in hazardous environments. You assume all risks for use of the Code.
> Use of the Code is subject to terms of the licenses to the UHD or RFNoC
> code with which the Code is used. Standard licenses to UHD and RFNoC can be
> found at https://www.ettus.com/sdr-software/licenses/.
>
> NI will only perform services based on its understanding and condition
> that the goods or services (i) are not for the use in the production or
> development of any item produced, purchased, or ordered by any entity with
> a footnote 1 designation in the license requirement column of Supplement
> No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a
> company is not a party to the transaction.  If our understanding is
> incorrect, please notify us immediately because a specific authorization
> may be required from the U.S. Commerce Department before the transaction
> may proceed further.
>
> On 16.02.21 08:33, Ofer Saferman via USRP-users wrote:
> > Hello,
> >
> > I would like to access sensor data like "gps_time",
> "ref_locked","gps_locked" using a
> > USRP device defined as "uhd::device3::sptr usrp" on a E310 unit.
> > All the examples are for USRP devices defined as
> "uhd::usrp::multi_usrp::sptr usrp".
> >
> > I searched the documentation and tried all possible combinations also
> using the
> > "uhd::rfnoc::radio_ctrl::sptr" object without any success.
> > I can see the method exists for multi_usrp and mb_controller objects. I
> know that the
> > mb_controller is somewhere accessible either through radio_ctrl object
> or the device3
> > object but I don't know how to get to it.
> >
> > Regards,
> > Ofer Saferman
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
> is
> > believed to be clean.
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to