Strange temp readings in armbian 5.8.16

[specialist383]

I am operating a headless data acquisition system with Orange Pi Zero Plus2. In the readings I collect among others data from a discrete separate 18B20 sensor and record the H3 CPU temperature.

The 18B20 reading comes from the w1 kernel routine, the CPU temp is provided by armbian OS.

With the new OS 5.8.16 I see a strange effect: reading ....

the external sensor at  /sys/bus/w1/devices/<sensID>/temperature    and

the CPU temperature at /etc/armbianmonitor/datasources/@soctemp

it gives the same reading correct to a 1/100 degree. Even when the system runs low power - this cannot be true.

I have no idea how these results can be mixed in the system. Reading the w1 result with checksum in 2 lines is identical to the result above.  So I guess something is wrong with the armbian SocTemp reading even though it could be correct within a couple of degrees. Apart from the readings the Orange Pi Zero board operates fine without major problems.

Any suggestions ?

 

 

[NicoD]

Hi. I don't fully understand your question. 
Could you be more precise? What you used before and what was temperature reading then?

I've had simular experiences with H3. Depends of what kernel, and either focal/bionic/Buster...
Kernel 4.19 runs very stable and, low temperature and lower power consumption. Vs 5.x running a lot hotter, throttles more quickly, isn't fully stable and consumes a bit more.

It it something simular you are experiencing?

[specialist383]

My physical system is an OrangePi Zero Plus2 board in a sealed enclosure outside. The 18B20 w1 sensor is on the outside of the box = ambient temperature. The other reading 'cpu temp' is inside the box provided by the OS, which must be somewhat higher physically due to the necessary heat transfer.

When with the 5.8.16 kernel I read the values provided by the OS, kernel w1 routine or ?armbian cpu soctemp, they come out identical. But the outside temperature of an enclosure cannot be identical to the internal temperature of an operating cpu, especially when the 5.8.* kernel may be not so efficient any more.

Funny enough: if I read "cat /sys/devices/virtual/thermal/thermal_zone0/temp", it returns 22.9 deg whereas armbianmonitor or "cat /etc/armbianmonitor/datasources/@soctemp returns 9.5 deg just as the w1 kernel reading.

I guess the 22.9 deg reading (cpu with small glued-on heatsink 13 deg warmer) is more likely true, so the armbianmonitor reading would be faulty.

I find it also surprising that running armbianmonitor alone with roundabout 0.5% cpu activity brings the cpu clock, set with cpufreq-utils to max, min and ondemand values, most of the time to max clock values.

I came to this new setup from a similar functional system with legacy kernel 3.*. I see some improvements with 5.8.*  but also drawbacks and strange effects.

 

 

[xwiggen]

What does below yield?

%  cat /sys/class/hwmon/hwmon0/temp1_input /sys/devices/virtual/thermal/thermal_zone0/temp /etc/armbianmonitor/datasources/soctemp

 

[specialist383]

Am 17.11.2020 um 00:33 schrieb xwiggen:

What does below yield?

%  cat /sys/class/hwmon/hwmon0/temp1_input /sys/devices/virtual/thermal/thermal_zone0/temp /etc/armbianmonitor/datasources/soctemp

 

cat /sys/class/hwmon/hwmon0/temp1_input :   14687

cat /sys/devices/virtual/thermal/thermal_zone0/temp : 32444

cat /sys/armbianmonitor/datasources/soctemp : 14062

cat /sys/devices/w1_bus_master1/28-000004648980/temperature : 13750

 

the w1 sensor 18B20 reads the outside case temperature (cold), zone0/temp is the ?CPU temp at a 5 min avg load of 0.02. Small differences in the low readings may come from the execution time difference. The CPU reading is usually 20 deg C higher than the case temp one. There is a heat sink attached to the CPU device (H3).

[Ilya Basin]

specialist383 did you manage to solve this mystery? I'm having the same problem. If Orange Pi Lite with Armbian 21.02.1 is able to detect an external 1-wire thermal sensor, then the "CPU temp" line shown at ssh login is actually the outside temperature.

[Ilya Basin]

I had to edit /usr/lib/armbian/armbian-hardware-monitor. Was:

 

        elif [[ -f /sys/class/hwmon/hwmon0/temp1_input && ${BOARDFAMILY} != "mvebu" ]]; then
                # usual convention with modern kernels
                ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
        else
                # all other boards/kernels use the same sysfs node except of Actions Semi S500:
                [[ ${BOARDFAMILY} == s500 ]] && THERMAL_ZONE="thermal_zone1" || THERMAL_ZONE="thermal_zone0"
                ln -fs /sys/devices/virtual/thermal/${THERMAL_ZONE}/temp /etc/armbianmonitor/datasources/soctemp
        fi

Now:

        elif [[ -f /sys/class/hwmon/hwmon0/temp1_input && ${BOARDFAMILY} != "mvebu" && ${BOARDFAMILY} != "sun8i" ]]; then
                # usual convention with modern kernels
                ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
        else
                # all other boards/kernels use the same sysfs node except of Actions Semi S500:
                [[ ${BOARDFAMILY} == s500 ]] && THERMAL_ZONE="thermal_zone1" || THERMAL_ZONE="thermal_zone0"
                ln -fs /sys/devices/virtual/thermal/${THERMAL_ZONE}/temp /etc/armbianmonitor/datasources/soctemp
        fi

 

Now thermal_zone0/temp wins over hwmon0/temp1_input