measuring the cpu temp and gpu temp in bash and python 3.5.3+ pi 2, 3B, 3B+, 4B, Buster

Question

Two part question.

Although these questions might sound more generally like linux questions, my need is to have these answers specific to the pi.

Part 1 - Does the raspberry pi 2, 3B, 3B+, 4B, have only one temperature sensor that measures the overall processor temperature, or does it have a separate sensor for the CPU, and an additional separate sensor for the GPU?

I have found posted solutions (answers) on half a dozen support forums that claim to measure both (implied separately) in a bash shell, but if there is only one sensor, I wish to simplify my script(s), and know that those posts that showed the GPU sensor, separately, were ... misleadingly misinformed or unclear ... by not explaining that there is in fact only one sensor that measures the cpu/gpu silicon.

Also, testing some of those posted answers for finding the gpu temperature (with vcgencmd measure_temp), those results were always 0 for the decimal, ie 45.0, while the cpu temperature results were often a non zero decimal value, such as 42.173.

Here, on the pi forum, someone with a title of engineer (something I respect) implies two sensors with his code... but please understand that I intend no offense to any person or title by focusing a bit on this. Any and every contributor, whether an engineer or not, may simply be faithfully communicating what is in the resources available to that person at that time. That is an unavoidable dynamic in any opensource community, something we embrace because of how great the benefits can be. In context, for me, reading the post of an engineer, among all the others, makes arriving at a final conclusion that much more confusing, since certainly I prefer to go with the word of an engineer, which then makes all other answers necessarily in an as yet undetermined tension with the engineer's answer (and maybe that is good as it may urge some to investigate further toward verification, if this issue is indeed as important as it is represented to be for particular project(s)).

Additional bash solutions I have found:

1: Suggesting there is a separate gpu to measure.

#!/bin/bash

cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 %$cpuTemp1))

echo "CPU temp=$cpuTemp1.$cpuTempM'C"
echo "GPU $(/opt/vc/bin/vcgencmd measure_temp)"

2: This was given as a solution in one post for cpu temp, and in another post for specifically the gpu temp. Which is it? Or is this an indicator that they are one and the same?

/opt/vc/bin/vcgencmd measure_temp

3: This was given as specifically for the cpu temp, and would then need to be divided by 1000 for celsius temperature.

echo $(cat /sys/class/thermal/thermal_zone0/temp)

4: This seems very similar to '2', except the vcgencmd is located in a different path. Does this mean it is measuring a different sensor, or the same one? Why the two occurences?

/usr/bin/vcgencmd measure_temp

Each of those 4 versions may have different issues of the format of the result, but most importantly to me, and other users who have asked similar question(s)... are there two separate sensors or only one?

Part 2 - I would like to capture these temperature(s) in a python3 script. How I do this will depend on whether there are two sensors or just the one for both cpu and gpu.

I have already found a solution for the cpu temperature in python3 (3.5.3+).

import gpiozero as gpz

cpu = gpz.CPUTemperature()
cpu_temp = cpu.temperature
print(cpu_temp)

46.251

If there is only one sensor, then I have my solution to Part 2. Or is there a better way with subprocess?

Edit:

I have included in my own answer, a function for reading the sensor by using subprocess instead.

Answer 1

This from:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md

"The SoCs have an internal temperature sensor, which software on the GPU polls to ensure that temperatures do not exceed a predefined limit; this is 85°C on all models."

One sensor.

And note the final section paragraph...

---

Measuring temperature

Due to the architecture of the SoCs used on the Raspberry Pi range, and the use of the upstream temperature monitoring code in the Raspbian distribtution, Linux-based temperature measurements can be inaccurate. There is a gencmd that can provide an accurate and instantaneous reading of the current SoC temperature, as it communicates with the GPU directly:

vcgencmd measure_temp

---

So that is the somewhat official word from raspberrypi.org documentation. I tried getting an answer from broadcom without success. I started a case with "arm developer", and it would be nice to hear from them, although, when broadcom puts an arm cortex A7 MPC in a package, and then that package is put on an SoC by yet another organization, I am unsure of how that would alter (or not) what is available more directly on the arm Cortex A7 MPC itself. Suffice it to say, raspberrypi.org states 'a sensor', which I read as 'one sensor', with one more recommended way in which to capture the moment's more precise measured temperature of that sensor, whether or not there are three or four different ways to get at that temperature.

Why one method of access might return a slightly different value than another, I suppose we are free to speculate. But there we have the word on the matter from the raspberrypi.org documentation, as of today, 30 November 2019. I will adapt and slim my project code accordingly. And if/when I hear from arm developer, I will edit this to include anything helpfully relevant they would share.

Final note: The method that this documentation recommends as the most instantaneous and accurate measurement, at least in Buster, seems to only return results that have no decimal component other than .0, while the other methods shown in other posts do show a varying decimal component. I wonder if it is because that method of poling the temperature puts the result in a single 8 bit register, unable to indicate a decimal component. The other methods perhaps average several readings over time, and therefore have a decimal component due to those averagings? Speculation. I'm letting it run for an hour to see if there is ever anything other than a n.0 value there. Result. Only n.0 values from vcgencmd.

So, if the documented method never returns a decimal component, and does indicate something like a minimally sized register holding the temperature value, then, other methods that return decimal values may indeed be averaging several recent recorded values, meaning, they slow things down slightly doing so, perhaps. So I'll go with one sensor, polled with

vcgencmd measure_temp

python3 example using subprocess, returning a string of the value. Of course, test the result as your needs require, to ensure that it is always valid numberic data. As of 12-02-2019 the string slice is correct.:

import subprocess as sproc

def get_pi_temp_sensor():
    '''
    For raspberry pi running Buster.
    '''

    p1 = sproc.run(["/opt/vc/bin/vcgencmd", "measure_temp"], 
                      capture_output=True, text=True)

    if p1.returncode == 0:
        # no errors so process the output
        temperature_error = 'No error'  # use this as you will in the call
        temperature = p1.stdout[5:-3]   # remove the surrounding text

    else:
        # there was an error
        temperature_error = p1.stderr

    return temperature, temperature_error

Update

I heard back from support.developer.arm.com regarding my question about any temperature sensor(s) on the Cortex A7 MPC used on the pi4B. The response clarified that there are no temperature sensors on the Cortex A7 MPC at all, but instead, Broadcom, who designed the BCM2711 package that utilizes the Cortex A7 MPC, was the one who decided how to, and then implemented all the support circuitry in the BCM 2711 for making that 'package' a SoC, including any temperature sensor(s). Broadcom apparently did implement one sensor in order to manage any need to throttle the clock speed, etc, in order to prevent any potential runaway thermal conditions in the cpu or gpu components of the BCM 2711 package, conditions that might otherwise cause irreparable damage (decreasing the life of the unit overall by a factor related to how much it overheats and for how long). To be clear, this is not my field of expertise, so I hope I communicated all this sufficiently correct so that it is useful. Therefore, if one wants a designer/manufacturer hardware "final answer" as to the temperature sensor(s) on the Broadcom 2711, one must hear from the proper Broadcom staff directly. I have not yet found the right pathway to the right person at Broadcom for that level of support. My answer consequently remains with a trust in the official documentation from raspberrypi.org, which states one sensor, where vcgencmd measure_temp will give the correct 'instantaneous' value of that sensor, which happens to be, in all my test cases, always a whole number value, that is to say, with a decimal value of zero. All other measurement methods in various other code snippets in various forums, that have decimal values other than zero, I suspect are due to those other methods doing some sort of averaging of multiple reads of that sensor, whereas the raspberrypi.org documented method does accomplish, by their own wording, one instantaneous read, and seems to always return a decimal value of zero through that recommended vcgencmd measure_temp. Once again, it leads me to conclude that code that attempts to read two different sensors is misleading and confusing code 'bloat'. If however, one knew exactly how the other reporting methods average multiple reads, such as the clock cycles between reads, and whether or not the decimal value returned by them is useful for establishing a trend of the temperature one way or the other, then the other methods may have some usefulness, if one needs that sort of exotic microsecond detail in a project. All this speculation arises out of the official documentation from raspberrypi.org, quoted at the top of this answer, which states one sensor, and gives only one method for acquiring an instantaneous read of that sensor, at least as instantaneous as a shell command can be with any of its system overhead relevant to defining what is instantaneous.

I have no intention to be confrontationally 'in tension' with anyone else's contribution. I am only making my own opensource community contribution, drawing a conclusion based on the official resources directly available to me, mainly, the raspberrypi.org documentation page as of this writing. And I have cited that source. If anyone has further insight into a better answer, it would be wonderful if a source could be supplied with that insight. Of course this is all relevant particularly to the pi platform and its Broadcom package(s). Other platforms may indeed have individual thermal sensors for each core and for the gpu(s).