Strontium

I needed a small zero cross detector to switch SSR's efficiently and properly in my DIY reflow oven so I designed these in KiCad, and built them. They are optically isolated (5000V Isolation) and Low power (less than 120mW) so are safe to hook up to any board supported by Armbian (or any other SBC) (provided you safely wired them to the mains) and produce a nice open drain low going pulse for 1ms (50Hz AC) centred dead around zero cross. (about 0.83ms for 60Hz AC). On the digital side they will interface to any logic level between 1.8V and 5V. The thing is I only need 2, and I have spares because I had to get 10 PCB's minimum. I have decided to build them all up, So, if anyone would like one, let me know I am happy to sell my spares. Useful for any project involving the switching of mains power, load monitoring, etc. I am not thinking about going into production of these, so once these are gone I likely won't be making any more. I designed the board to be hard wired to the mains and then heatshrinked so that no High voltage is exposed in operation. However they can take a screw terminal if one is so inclined. Send me a PM if your interested in getting one, and otherwise I am happy to discuss the boards here in this thread. Obviously these are connecting to mains which can be lethal if you are careless or stupid, so anyone doing this sort of project needs to take the appropriate precautions, and know what they are doing. That said, once these are safely wired up to the mains, and then encapsulated, they should be quite safe and present no danger to connected equipment.

I would still be checking temperature. Just in case. The maximum CPU frequency that the kernel will use will drop if temperature goes too high. So you may not be seeing the whole story just by looking at cpu frequency and Top.

brkl stuttering in any program sounds like a performance issue. OPI-Zeros overheat without heatsinks, and then thermal throttle (slow down). Its possible your OPI Zero is doing that, try running armbianmonitor on a seperate ssh connection while running Chuck. it will tell you if your orange pi zero is overheating and therefore being slowed down.

brkl is correct. Configuration of the Kernel for sunxi-next defaults to Sequencer Support being disabled (At least for Orange Pi Zero). It should be enabled as a Module. it is in: > Device Drivers > Sound card support > Advanced Linux Sound Architecture The Help for the kernel option goes on to say: Which means that it should be enabled, or set as a module by default, and not disabled by default. I don't know if the Allwinner support is there for HR Timers. But if they do support them, then the options: "HR-timer backend support" "Use HR-timer as default sequencer timer" should also be set as Modules. Under Generic Sound Devices, "Virtual MIDI soundcard" should also be set as a module. Interestingly, under USB Sound Devices, "USB Audio/MIDI Driver" is set as a module, as is "Behringer BCD2000 MIDI driver" and others. These will be useless without Sequencer support. BRKL: If you want to help yourself, you should look at the instruction for building Armbian. Follow them through, its not too difficult, and you can build your own image and kernel with these options enabled, until such time as they become standard. (And maybe there is some valid reason why they have been disabled in the general case, in which case this may be your only recourse).

I don't know the exact answer to your question, but i do know that stretch will only build with the Mainline kernel or the Dev one. If you choose "legacy" and then try and build a stretch image it will object. At least for Allwinner H2/H3.

Just an update, X installs and runs fine on the Orange PI Zero using my patch. HOWTO: Install a desktop using sudo tasksel after its all finished properly, reboot. You will then get this: https://imgur.com/a/seu9t if you want to change video mode, you can do it with xrandr like this: DISPLAY=:0 xrandr --output Composite-1 --mode NTSC DISPLAY=:0 xrandr --output Composite-1 --mode PAL You only need the "DISPLAY=:0" if you are doing the mode setting from a ssh terminal. Supposedly xrandr can scale the desktop and move it around (which could help with the overcan problem) but i couldn't get it to work in the 5 minutes I allocated to testing it.

Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian. It seems to work totally fine, with a few caveats. First: Sample images of it in action -> https://imgur.com/a/vXQEM Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11 Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11 Howto: just put the patch into userpatches for the sunxi-next kernel, and build. it should apply cleanly. Its for H2+/H3. I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards. You then need to edit /boot/armbianEnv.txt add tve to overlays to enable it. the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this. If you want to turn TV out off, just remove tve from the overlays line. My armbianEnv.txt overlays looks like this: overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well: extraargs=drm.debug=0xF Its not needed, unless you really want the debug info. Notes: 1. The default mode is PAL, with 720x576 resolution. Thats outside of normal PAL displayable area, and so the screen overscans. I dont know how to correct this, although its mostly just annoying with terminals. I also don't know how to change the video mode to NTSC. 2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity. Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded. A way to resolve this is use : # apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one. its much easier to read. Look at the help for fbterm to work out everything it can do. 3. I used the program "fim" to display the test images. there are others for doing stuff on the terminal. 4. I haven't tried X. I am not interested in running an X terminal on a TV, but it should probably work fine. Other than that it all seems good. I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy) The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND. i soldered one inside my RCA connector, it fits fine and isn't too difficult. IF you don't do this the image will bloom and look like total crap, so you have been warned. As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it. I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build. If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian. EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver. I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system. Original code is here: https://github.com/Icenowy/linux/tree/tve-v2