Hello,
Here are some C++ code snippets for reading all the temperatures:
-----------------------------------------------------------------------
uhd::device3::sptr usrp = uhd::device3::make(args);
int temp_mb =
usrp->get_tree()->access<uhd::sensor_value_t>("/mboards/0/sensors/temp_mb").get().to_int();
int temp_fpga =
usrp->get_tree()->access<uhd::sensor_value_t>("/mboards/0/sensors/temp_fpga").get().to_int();
int temp_ad9361 =
usrp->get_tree()->access<uhd::sensor_value_t>("/mboards/0/dboards/A/tx_frontends/0/sensors/ad9361_temperature").get().to_int();
std::cout << "Motherboard temp=" << temp_mb << std::endl;
std::cout << "FPGA temp=" << temp_fpga << std::endl;
std::cout << "AD9361 temp=" << temp_ad9361 << std::endl;
-----------------------------------------------------------------------
If your USRP object is multi_usrp it is easier. There is a method called
get_mboard_sensor() or something like that makes the code more pretty. The
sensor name is as above.
How did you install lm_sensors?
Regards,
Ofer Saferman
On Wed, Aug 25, 2021 at 2:02 AM <[email protected]> wrote:
> Send USRP-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."Today's Topics:
>
> 1. Re: Reading E310 temperatures (aneesh patel)
> 2. Re: Reading E310 temperatures (aneesh patel)
> 3. Re: Reading E310 temperatures (Rich Gopstein)
>
>
>
> ---------- Forwarded message ----------
> From: aneesh patel <[email protected]>
> To: Rich Gopstein <[email protected]>, Marcus D Leech <
> [email protected]>
> Cc: "[email protected]" <[email protected]>
> Bcc:
> Date: Tue, 24 Aug 2021 22:19:49 +0000 (UTC)
> Subject: [USRP-users] Re: Reading E310 temperatures
> Concur on verifying-- that being said I know at least one of them
> (possibly CPU) was available on the SG3 image a while back (I'm sure
> nothing much has changed there but its been a while).
>
> Then is would be very simple to write a simple custom GNURadio block (like
> basically a command line script to cat the sensor file descriptor [just
> google that as I can't recall if its in /sys or /proc]) to pull that data
> from the OS to pass temp messages and ingest them into your message passing
> or logging system. On the tougher end, depending on dev cycles, one can
> cross-compile or pull code from lm-sensors and then turn that into a
> GNURadio block (and maybe even being able to add the other sensors when
> reading into the ettus kernel mod code/schematics if possible). Some
> options exist.
>
> Going all from memory here but that should be >94.27% correct. :)
>
> Best of luck!
>
> Aneesh
>
> On Tuesday, August 24, 2021, 05:20:51 PM EDT, Marcus D Leech <
> [email protected]> wrote:
>
>
> My approach would be to see if any of those sensors are understood by the
> kernel lm_sensors subsystem.
>
> Sent from my iPhone
>
> > On Aug 24, 2021, at 5:12 PM, Rich Gopstein <[email protected]>
> wrote:
> >
> >
> > I'm helping out on a project that's using an E310. Someone else is
> doing the GNURadio code, but I need to read the temperature values
> periodically (once every few seconds). My code will not be running in
> GNURadio.
> >
> > It looks like there are three temp sensors (Zynq, ADT7408, and the
> AD9361).
> >
> > What are my options for reading the temp values outside of GNURadio? If
> it matters, the E310 is running UHD_3.15
> > My code will be running on the E310 directly.
> >
> >
> > Thanks.
> >
> > Rich
> >
> > _______________________________________________
> > USRP-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> USRP-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
>
> ---------- Forwarded message ----------
> From: aneesh patel <[email protected]>
> To: Rich Gopstein <[email protected]>, Marcus D Leech <
> [email protected]>
> Cc: "[email protected]" <[email protected]>
> Bcc:
> Date: Tue, 24 Aug 2021 22:25:27 +0000 (UTC)
> Subject: [USRP-users] Re: Reading E310 temperatures
> Correction-- missed you said "outside of gnuradio." Basically everything
> below minus gnuradio. if the sensors_lm package is available (as marcus
> stated), parse that output or just manually parse the /sys or /proc (forgot
> which one) file descriptor for the sensor when you find it.
>
> Best of luck!
>
> Aneesh
>
> On Tuesday, August 24, 2021, 06:19:49 PM EDT, aneesh patel <
> [email protected]> wrote:
>
>
> Concur on verifying-- that being said I know at least one of them
> (possibly CPU) was available on the SG3 image a while back (I'm sure
> nothing much has changed there but its been a while).
>
> Then is would be very simple to write a simple custom GNURadio block (like
> basically a command line script to cat the sensor file descriptor [just
> google that as I can't recall if its in /sys or /proc]) to pull that data
> from the OS to pass temp messages and ingest them into your message passing
> or logging system. On the tougher end, depending on dev cycles, one can
> cross-compile or pull code from lm-sensors and then turn that into a
> GNURadio block (and maybe even being able to add the other sensors when
> reading into the ettus kernel mod code/schematics if possible). Some
> options exist.
>
> Going all from memory here but that should be >94.27% correct. :)
>
> Best of luck!
>
> Aneesh
>
> On Tuesday, August 24, 2021, 05:20:51 PM EDT, Marcus D Leech <
> [email protected]> wrote:
>
>
> My approach would be to see if any of those sensors are understood by the
> kernel lm_sensors subsystem.
>
> Sent from my iPhone
>
> > On Aug 24, 2021, at 5:12 PM, Rich Gopstein <[email protected]>
> wrote:
> >
> >
> > I'm helping out on a project that's using an E310. Someone else is
> doing the GNURadio code, but I need to read the temperature values
> periodically (once every few seconds). My code will not be running in
> GNURadio.
> >
> > It looks like there are three temp sensors (Zynq, ADT7408, and the
> AD9361).
> >
> > What are my options for reading the temp values outside of GNURadio? If
> it matters, the E310 is running UHD_3.15
> > My code will be running on the E310 directly.
> >
> >
> > Thanks.
> >
> > Rich
> >
> > _______________________________________________
> > USRP-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> USRP-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
>
> ---------- Forwarded message ----------
> From: Rich Gopstein <[email protected]>
> To: "[email protected]" <[email protected]>
> Cc:
> Bcc:
> Date: Tue, 24 Aug 2021 19:02:21 -0400
> Subject: [USRP-users] Re: Reading E310 temperatures
> Thanks for both suggestions. I installed lm_sensors, and it seems to find
> two of the temp sensors. Not sure which two, though:
>
> # sensors
> e31x_battery-virtual-0
> Adapter: Virtual device
> temp1: -273.0°C
>
> e000b000ethernetffffffff00-mdio-0
> Adapter: MDIO adapter
> temp1: +28.0°C (crit = +100.0°C)
>
> jc-42.4-temp-i2c-0-19
> Adapter: Cadence I2C at e0004000
> temp1: +33.2°C (low = +0.0°C) ALARM (HIGH, CRIT)
> (high = +0.0°C, hyst = +0.0°C)
> (crit = +0.0°C, hyst = +0.0°C)
>
>
> On Tue, Aug 24, 2021 at 6:25 PM aneesh patel <[email protected]>
> wrote:
>
>> Correction-- missed you said "outside of gnuradio." Basically everything
>> below minus gnuradio. if the sensors_lm package is available (as marcus
>> stated), parse that output or just manually parse the /sys or /proc (forgot
>> which one) file descriptor for the sensor when you find it.
>>
>> Best of luck!
>>
>> Aneesh
>>
>> On Tuesday, August 24, 2021, 06:19:49 PM EDT, aneesh patel <
>> [email protected]> wrote:
>>
>>
>> Concur on verifying-- that being said I know at least one of them
>> (possibly CPU) was available on the SG3 image a while back (I'm sure
>> nothing much has changed there but its been a while).
>>
>> Then is would be very simple to write a simple custom GNURadio block
>> (like basically a command line script to cat the sensor file descriptor
>> [just google that as I can't recall if its in /sys or /proc]) to pull that
>> data from the OS to pass temp messages and ingest them into your message
>> passing or logging system. On the tougher end, depending on dev cycles, one
>> can cross-compile or pull code from lm-sensors and then turn that into a
>> GNURadio block (and maybe even being able to add the other sensors when
>> reading into the ettus kernel mod code/schematics if possible). Some
>> options exist.
>>
>> Going all from memory here but that should be >94.27% correct. :)
>>
>> Best of luck!
>>
>> Aneesh
>>
>> On Tuesday, August 24, 2021, 05:20:51 PM EDT, Marcus D Leech <
>> [email protected]> wrote:
>>
>>
>> My approach would be to see if any of those sensors are understood by the
>> kernel lm_sensors subsystem.
>>
>> Sent from my iPhone
>>
>> > On Aug 24, 2021, at 5:12 PM, Rich Gopstein <[email protected]>
>> wrote:
>> >
>> >
>> > I'm helping out on a project that's using an E310. Someone else is
>> doing the GNURadio code, but I need to read the temperature values
>> periodically (once every few seconds). My code will not be running in
>> GNURadio.
>> >
>> > It looks like there are three temp sensors (Zynq, ADT7408, and the
>> AD9361).
>> >
>> > What are my options for reading the temp values outside of GNURadio?
>> If it matters, the E310 is running UHD_3.15
>> > My code will be running on the E310 directly.
>> >
>> >
>> > Thanks.
>> >
>> > Rich
>> >
>> > _______________________________________________
>> > USRP-users mailing list -- [email protected]
>> > To unsubscribe send an email to [email protected]
>>
>> _______________________________________________
>> USRP-users mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> USRP-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
