specialist383

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).

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.

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 ?

FYI as additional information: due to WIFI problems I changed a outside monitor box from OpiZero-256 (old version) to OpiZero2Plus with H3 processor. After turning down all unnecessary interfaces in the fex file, the H3 CPU idles now at a temperature 1-5 deg C higher than ambient, with minimal power consumption. In the weather-proof closed box (140x80x50 mm) there is a 18B20 sensor close to the OpiZero board, on the H3 I have a small 14x14 mm heat sink. The initial setup with the 'old' OpiZero-256 survived even full sunshine and a box temperature of ~75 C. The old WIFI worked fine until the system went to sleep and usually never woke up.

I checked the Orange Pi Zero Plus2 datasheet .v1, the table above and the pins that work in my OpiZeroP2 controller and came up with a pinout diagram of the GPIO connector referenced to port and pin numbers. Pins 11 and 13 seem to be strange. For Python users, not all pins are usable in a program using the pyA20-H3 driver and its (incomplete) mapping. The function of most of the pins depend on the H3 internal function activated in the fex/dtb file during boot.

[Solved] With the above input I finally made the OpiZero2Plus board work like the standard OpiZero board with legacy kernel. The 2Plus board requires in the fex file ... [w1_para] w1_used = 1 w1_gpio = 110 to attach the 1-wire sense line to pin (GPIO-conn) 26 The gpio pins PD11 and PA16 are not defined in the pyA20 mapping. As an alternative I use [gpio_para] gpio_used = 1 gpio_num = 3 gpio_pin_0 = port:PA13<1><1><1> => pin GPIO-conn 23 out gpio_pin_1 = port:PA14<1><1><1> => pin GPIO-conn 24 out gpio_pin_2 = port:PA18<0><default><default><1> => pin GPIO-conn 18 in these used as SPI-CSEL, SPI-CLK and SPI-DATA with a MCP3201 A/D converter. When using these pins, some other H3 functions need to be disabled in the .fex/.bin file to avoid a double functional assignement. To disable hdmi, bluetooth etc (if not needed) helps to save power. The kernel CPU temp is now correct. Below is a text file with the required changes in ....fex/bin to support a standalone monitor/control device. Maybe this helps. opizeroplus2-h3.fexinfo.txt

Last year I started a solar-sensing project with the Orange-Pi-Zero (256k), Armbian5.25, legacy kernel and made it work after a while. The Wifi funktion was rather poor and deteriorating, so I ordered a new OpiZero-Plus2-H3, same physical shape and connectors (I thought). Now the -P2 Armbian image 5.30 for the new board loaded perfectly, the Wifi function is really improved due to better hardware. The python part of the code works (still) perfectly. Only (most of) the gpio-functions of my project do not work any more with the new board attached. I use PA07, PA13 and PA14 for bit-bang gpio and a 1-wire sensor via the kernel. I modified the OPi-P2 fex file, shipped with Armbian, turning off hdmi and SPI functions the same way as before, setting min clk to 408 MHz and max clk to 1200 MHz. Powersaving seems much improved. I checked the fex file for other connections to my nodes - nothing. I loaded the kernel drivers as before. But the result is: PA13 and PA14 work as before, the PA7 input pin does not see any levels (open), the 1-wire device is not recognized, neither the old or a brand-new component. I am pretty stuck - the alternative pin PA16 cannot be activated because it is not mapped in the pyA20-H3 driver. The author duxingkei33 writes the mapping can be expanded, but I could not find enough information how to define the extra parameters. The SPI built-in interface would use PA 13,14,16 but they are not all included in the pin mapping. Q: is the 1-wire function in the new Armbian for OpiZero-P2 already a tested function? Is there something new with the gpio-connector? Is there any more information available about the pin and connectors mappings for the pyA20-H3 driver? Is there already any other I/O-experience with the new Zero-P2 board around ? After quite some hours I am running out of ideas to fix it. I added the modified/reduced fex file. orangepizeroplus2-h3.fex