bozden

Great work... Good to have someone with the knowledge, skills and equipment. Is there any possibility that you have calibrated equipment to measure the case temperature in each step? I'm pretty sure untempered v1.4 boards run quite a lot hotter (ref. finger test).

Well, of course you know much better, I only used it on OPi devices and legacy OS. I wrote an installation script similar to what DietPi does (1's or 0's to turn features on and off). If GPIO is on, it handles the groups/users stuff, downloads and compiles related repository for WiringPi. Much work to go of course for adding stuff like MQTT or OpenHub etc. But I'm sure it will be much difficult for so many devices and multiple OS versions...

Why not add it into armbian-config?

I've got confirmation that the links are corrected, I waited for them to announce it here but anyway. @Igor can you please cross-check it if you have time

I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...

Well, I'm pretty sure they can understand English. But I'm here to help of course... We are already in contact with @guidol

@mebinpm Awhile ago I was the one who opened such a discussion here and got lots of help... It did not completely solve it but turning off/on the HDMI was the solution... I did it though a C program I wrote (the setup has a shutdown button)...

Are you after a next-gen Blackberry?

These figures are consistent with my results in the original post. Even 3-4 degrees hotter, but that may depend on the environment...

It also not so easy to measure the ripples of the SPS's with an oscilloscope. I tried and failed... Grounding, noise etc play a major role and my setup could not overcome these... Very good PIN-UP btw

@chwe I can do that on Wednesday. But what do you expect? When the old version crashed there was a nice odor of electronics (I'm not sure if the board is OK yet). But my point is: It is the OPi Zero case that causes the problem, as there is no airflow design. Without the case it ripples around 55-56 C with "aplay" running.

I used the case yesterday with a v1.1 PCB OPi zero for testing. It was just running "aplay" looping though some songs (strictly less than %5 CPU load). The test started at 46 C and reached 65 C in 10 minutes (full power limit). And 5 minutes after that I had a full system failure and it did not start again (I'll look into it when I have time). So I threw the case away. In this current status the box is not usable without active cooling. As the expansion board covers the SOC a fan on the top does nothing and the sides are also not an option. One side is covered by the expansion board's header and I wanted to spare the other side for I/O as you will do - and that would require a ribbon cable which also should prevent airflow. I asked for an alternative design in their forums but I think a 3D-printed case designed for you application is the only viable option as @chwe suggests.

Thank you. That was what I was looking for I think best way is to clone the build repository and check the differences...

Where can I follow detailed changes in (legacy) Armbian builds? Things such as: motd structure change introduce/remove Network Manager ... I have lots of setup scripts manipulating (e.g. using sed) the default Armbian files and they break if stuff changes... Are these changes coming from Ubuntu or from Armbian? Thanks a lot.

Sorry, I don't get this... Do you want to use a USB sound card as a IR transmitter/receiver?

In all of uses I decided to add a small 5V 30x30 fan to the design. Yesterday in one of the installations (OPi One based push-button video player) the cable got disconnected during installation and today it shows bad symptoms... It is in a controlled museum air conditioning. Adding that fan keeps the temperature below 40 C at all times (OPi one). Yes it depends on the use case but for any "professional" application I would not gamble... In addition to v1.4 gamble

I don't know anything on mainline kernel, never used it. Do you know what the difference as far as DVFS is concerned?

In the OP armbianmonitor -m output of the v1.4 board (OPiZ-3) states that the frequency on idle is 240 MHz which is very low, and actually not usable for real applications. The FEX file is: LV6_freq = 240000000 LV6_volt = 1100 So, do you think one should lower the voltage? We don't have the schematics, so I cannot look at it either. Can the SoC run under that voltage?

Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian. From the end-user perspective, something like this would be invaluable for me: https://www.w3schools.com/cssref/css3_browsersupport.asp If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously. A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells 2c

This is the way to go with a solar powered remote device I think... But I know the drill, it introduces many development issues.

I just want to share what I examined yesterday... Background: I used OPi one to output HDMI video when a button is pressed. It has an attached fan, a remote shutdown button and a remote switch to turn power off-on (OPi is hidden and operated through these buttons). It worked on breadboard, produced 2 working examples, tested the first two with a 24h test. All fine... Problem: On a third installation after the "circuits" are built, I made a last test. HDMI output had problems Sound comes and goes with a hick-up... Debugging: Checked wiring, checked with other video, checked with other OPi etc. Nada... The problem persisted. Lastly I checked the voltages. The output from the 2A power supply is 5.3V, (it goes to the switch and comes back) and the input to OPi is about 4.7-4.8 V !!!!! What the heck... I measured the full two way resistance of the power switch "circuit" as 1.2 Ohms. Well, not much Ohms law does not say so. Opi amperage is around 0.3-0.55 A in my application depending on video usage. Assuming 5 V and 0.5 A, the voltage drop on 1.2 Ohms line is 0.6 volts. Huh, this makes it 4.7 V on OPi... Knowing possible issues beforehand I used quality 23 AWG full copper FTP CAT6 cables for data lines, but just used simple 2x1.5mm2 power cable - a 5.4 mt long two way trip. But it was not the problem either... Measured the switch, measured the 5.4 mt cable... But: I used some cheap jumper cables (which I ordered from China), and connected the switch to a protoboard with them (easy to solder and plug), and those 2x20 cm cables had a huge resistance... I connected the switch with a thick cable and voila, the voltage at OPi is 5.0 V... Other installations did not have this issue because the wire lengths were now so high. Just wanted to share for those having issues... Bad voltage may manifest itself in very different ways. Actually, the most problematic part while working with *Pi's is usually the USB power cable quality. What happens to your phone (did I hear you complain on slow charging?) also happens here. In my experience a simple SMPS with 2A rating usually works well in those amperage, but cheap power cables suck ! Did we get through all our copper resources on this planet? Damn!

Nothing that I know. I keep using a fan...

OK, I had this working for a while now... One thing left. I don't know where it comes from (this is Orange Pi One Armbian 5.31 Legacy Ubuntu Desktop now): When a GPIO button is pressed (a C interrupt handler routine) I show an image, call system shutdown and turn off the HDMI as suggested. All execute fine for a while. After 10 seconds or so, HDMI becomes enabled as my application auto-starts again. Then it terminates, desktop shown for a short while, drops to login prompt and does shut down correctly. It is as if the X autologin user is executed during shutdown. What can be the reason of this behavior? Where can I check it? Another thing I recognized is the green LED on the boards keep lit after shutdown. I don't know when this started, it is in a kind of case (cat-safe ). Any idea why?

I didn't try smplayer. But there are options in mpv to handle these. Check: https://mpv.io/manual/stable/ --screen=<default|0-32> In multi-monitor configurations (i.e. a single desktop that spans across multiple displays), this option tells mpv which screen to display the video on. Note (X11) This option does not work properly with all window managers. In these cases, you can try to use --geometry to position the window explicitly. It's also possible that the window manager provides native features to control which screens application windows should use. See also --fs-screen. --fullscreen, --fs Fullscreen playback.

@spottyrover When I started a couple of months ago I hit these questions too... As Igor suggests install the Armbian Legacy Ubuntu Desktop and you have a go. If the video does not play on this distribution, it is because of the codec, and you have no chance here except transcoding. My mp4 files did not work, I created H264 mkv files which worked. On Orange Pi One I had success with 1080p 10MBps+ When you are playing from terminal, it will show what it is doing (hw/sw decoding etc). If you don't want to play with the mpv config file(s), you just use command line arguments: mpv --fs --vo=vdpau --hwdec=vdpau /path/to/file Actually "vdpau"a are already default... There are too many options in mpv, don't get lost