ag123 got a reaction from matrasa in Orange Pi PC old OS image
just like to share my 2 cents as i'm using 5.59 Debian stretch image on Orange Pi PC
if you have been using the 'old' images e.g. 3.x series, that is quite different from stretch (i've not tried bionic) which uses 4.x kernels. the 4.x kernels are mainline linux kernels.
the old 3.4 kernels uses some of the binary blobs like FEX etc distributed by Allwinner et.al. 4.x kernels are mainline linux kernels and FEX is not there as FEX Is propriety and the binary blobs is close sourced. 4.x mainline kernels has some of the old 3.x functionality reverse engineered open sourced and the features are pretty functional but not all of it.
i've used the 5.59 ubuntu stretch (mainline kernel 4.14.65 image for orange pi pc and do note that it is a cli (command line based) image
HDMI works for me in 5.59 Ubuntu Stretch mainline image, connect a usb keyboard and mouse to work on it like a PC
i'm not too sure if the Orange Pi PC you have bought a year back is after all the same as that i bought just recently, but based on the specs i think it should be pretty much the same. I'm not too sure if things may have changed between the year. If things are the same, install the image on a new (or different) SD card
(i work in linux and simply did
dd if=Armbian_5.59_Orangepipc_Debian_stretch_next_4.14.65.img of=/dev/<the sdcard device> bs=1m
to write the image to the sd card.
and boot that on the Orange Pi PC, it should boot and should leave you on the command prompt in HDMI asking you to logon. be a little careful with the initial password changes as you would need the new changed passwords after the initial logon and user creation. i made some mistakes and got locked out initially.
ssh needs to be setup anew as the os is reinstalled. i think if you are used to access the sbc as orangepipc.local. you may find that ping etc didn't turn up orangepipc.local.
i found out that that is mainly because avahi-daemon (i.e. mdns) is not installed on the orange pi pc. what i did is to do apt-cache search avahi on the sbc and install the avahi-daemon (e.g. apt-get install avahi-daemon) and subsequently i'm able to ping my board as orangepipc.local connected on the ethernet. i'm not using any wireless dongle.
after that ping and ssh to the hostname orangepipc.local works.
if you want to install the desktop, you need to run the commands:
- apt-get upgrade armbian-config
- armbian-config as root
and there is an option to install the desktop
Note that a new image Armbian 5.60 may be released soon, if you want that earlier, you could run apt-get upgrade armbian-config followed by armbian-config and switch to the nightly build
if things are still not working for you, you may want to fall back to the Xenial 3.4 image instead, as you have mentioned it seem to work well for you
i won't be able to help much with the wifi dongle but in armbian-config i think there is something like install/upgrade firmware package. i found that the 'firmware package' distribute quite a number of blobs and some of it seem to be related to wifi chips. you could try that to see if it helps. and this is for the stretch image and i'm using the nightly builds
ag123 got a reaction from Moklev in Next major upgrade v5.60
@Moklev i'd suggest monitoring and tracking down the root cause of the ssh woes, one of those ways is to connect via a serial console when ssh fails
try to connect a cable via the micro usb OTG port to see if you get a linux console presented. if that works when ssh fails you could then 'get into' the board and do some checks like a armbianmonitor -u
(if network fails you may need to run armbian monitor -U and saving the logs to a file)
among the things check /sbin/sysctl -a |grep vm.swappiness
vm.swappiness = 100
check in /etc/sysctl.conf if it is defined there you may like to reduce that value to 50 (or even for tests 0) to see if it made a difference
there could also be other ways like hacking up a script to say ping the router every 5 minutes and if ping fails to capture a log like armbianmonitor -U > logfile
on a side note, i'd think 5.60 is still a useful 'milestone' to have
ag123 reacted to tkaiser in Quick review of Orange Pi One
The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown.
Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One
The most important differences between One and PC as follows:
Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180Â° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store.
So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer.
The Orange Pi PC fits exactly:
And that's how it looks with the One:
You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180Â° rotation).
Different voltage regulator and the consequences:
Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity.
Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC.
On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board).
Fex/script.bin fixes necessary when using OS images for PC:
When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this:
[ARISC ERROR] :message process error [ARISC ERROR] :message addr : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr : 2 [ARISC ERROR] :message type : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings
At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment.
So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values.
How does voltage switching works on the One?
So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state:
pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same:
pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use
pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read:
pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important.
Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues.
Final chapter: Software support for the Orange Pi One:
First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too.
In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!)
Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One)
It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time.
And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress
Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working.
EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress.
ag123 reacted to tkaiser in Quick Review of NanoPi K1 Plus
Quick look at NanoPi K1 Plus. As usual comprehensive documentation available in FriendlyELEC's wiki.
Board is based on Allwinner H5 (able to clock up to almost 1.4GHz thanks to I2C accessible voltage regulator) and is compatible to RPi form factor. It comes with 2 GB dual-channel DRAM, Gigabit Ethernet and RTL8189 based Wi-Fi, exposes the three USB2 host ports as type A receptacles and USB OTG on Micro USB. The board also uses FriendlyELEC's own eMMC connector. Why they invented an own one can be easily seen on NanoPi NEO4: saves PCB space.
Powering is possible through Micro USB (high quality Micro USB cable is provided). Besides that the usual interfaces are available at the usual locations but not everything is supported currently by Armbian (e.g. CSI camera input -- you need to take FriendlyELEC's software offers for this).
Currently Armbian settings are a bit limited (max cpufreq 1152 MHz) but in the future we might unlock higher clockspeeds (up to 1368 MHz). Also needing some corrections: the thermal settings since currently the SoC starts to throttle already at 65°C.
Since FriendlyELEC sent an 8 GB eMMC module and I had my usual EVO840 lying around I checked storage performance using our usual iozone calls:
8 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 6830 7119 13905 13917 12040 6914 102400 16 20064 20519 31848 31884 29348 19759 102400 512 29217 28815 44536 44529 44325 28363 102400 1024 29247 29291 44801 44796 44678 29084 102400 16384 28519 29488 45031 45025 45025 29227 Samsung EVO840 via USB2/UAS random random kB reclen write rewrite read reread read write 102400 4 8550 10913 8310 8321 8337 10888 102400 16 21807 24395 21737 21809 21860 25063 102400 512 37468 37704 40780 41035 40997 37808 102400 1024 37929 38104 41271 41499 41488 38119 102400 16384 37099 38329 41796 41946 41958 38313 1024000 16384 38249 38414 41976 41997 So USB2 storage performance couldn't be better with nice high random IO scores and sequential transfers maxing out at ~40MB/s. But there's some room for improvement wrt eMMC. Just 29/45 MB/s write/read are not that spectacular though random IO numbers are excellent!
Network performance: Wireless not worth to test (2.4 GHz with 1T1R antenna setup will max out at 40 Mbps), with Gigabit Ethernet it looks fine (iperf3 test):
RX direction: [ 4] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec sender [ 4] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec receiver TX direction: [ 4] 0.00-10.00 sec 1.02 GBytes 879 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.02 GBytes 878 Mbits/sec receiver
I added preliminary sbc-bench results here and there is full debug output: http://ix.io/1m3J
ag123 reacted to tkaiser in Quick Review of NanoPi K1 Plus
I ordered a bunch of copper shims of various sizes and heights last year on Aliexpress but had no clue where I put it. Found it yesterday evening and immediately gave it a try.
In the following I use a copper shim of 15x15mm in size and 0.8 mm height to connect heatsink and H5 SoC with a thin film of thermal compound. Since I fear shorting something around the SoC area I simply used the 1mm thermal pad I had left from my RockPro64 (after replacing it with a copper shim there too). It's super easy to cut these thermal pads so I simply did exactly this:
Now repeating the 'sbc-bench.sh -T 64 ; sbc-bench.sh -t 45' with the board in open enclosure lying flat on the surface (full output):
Throttling statistics (time spent on each cpufreq OPP): 1152 MHz: 273.18 sec 1104 MHz: 27.14 sec 1056 MHz: 0 sec 1008 MHz: 0 sec 960 MHz: 0 sec 912 MHz: 0 sec 816 MHz: 0 sec 648 MHz: 0 sec 408 MHz: 0 sec Let's compare with the thin thermal pad from above. Both tests with same improved thermal settings (starting to throttle at 75°C) it's pretty obvious to realize where the real problem is: between SoC and heatsink:
thermal pad copper shim 1152 MHz: 76.09 sec 273.18 sec 1104 MHz: 36.09 sec 27.14 sec 1056 MHz: 165.10 sec 0 sec 1008 MHz: 23.04 sec 0 sec 960 MHz: 0 sec 0 sec Thermal pads suck!
Interconnecting SoC and heatsink in a more efficient way (0.8mm copper) greatly improves heat dissipation from SoC to heatsink. And that's the culprit.
Edit: Repeated the test twice now with top cover assembled (fully enclosed). Two times since the PCB has its own thermal mass and air and components are expected to 'store' some heat over time:
open enclosure with top cover thermal pad copper shim 1st run 2nd run 1152 MHz: 76.09 sec 273.18 sec 175.52 sec 163.46 sec 1104 MHz: 36.09 sec 27.14 sec 72.72 sec 67.07 sec 1056 MHz: 165.10 sec 0 sec 52.10 sec 69.81 sec 1008 MHz: 23.04 sec 0 sec 0 sec 0 sec 960 MHz: 0 sec 0 sec 0 sec 0 sec
So... tiny enclosures also suck!
But please keep in mind: sbc-bench is using cpuminer which makes heavy use of NEON optimizations. With more lightweight stuff like stress-ng, sysbench or 'full server load' my cooling setup is already sufficient to keep the SoC at above 1100 MHz even under full load. This is NanoPi K1 Plus in enclosure with 0.8mm copper shim between SoC and heatsink running 'sysbench --test=cpu --cpu-max-prime=200000000 run --num-threads=4' after 15 minutes:
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 12:59:35: 1152MHz 4.01 100% 0% 99% 0% 0% 0% 63.8°C 0/8 12:59:40: 1152MHz 4.00 100% 0% 99% 0% 0% 0% 63.4°C 0/8 12:59:45: 1152MHz 4.00 100% 0% 99% 0% 0% 0% 64.0°C 0/8 12:59:50: 1152MHz 4.00 100% 0% 99% 0% 0% 0% 63.8°C 0/8
ag123 reacted to tkaiser in Quick review of Orange Pi PC
Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning. Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus'). The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub") In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs). The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably. Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below. Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki. Getting started To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery) In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!) Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well) On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair: If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20Â°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI). Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me. I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!) Consumption/temperatures in headless mode: The OPi PC idles at 240-600MHz: 1.5W, 20Â°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC. Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores: 240 MHz: not exceeding 2.0W, 25Â°C above ambient temperature 600 MHz: not exceeding 2.5W, 32Â°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50Â°C above ambient temperature 2 CPU cores deactivated and testing again: 240 MHz: not exceeding 1.9W, 23Â°C above ambient temperature 600 MHz: not exceeding 2.1W, 29Â°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40Â°C above ambient temperature The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense. Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed. Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago. Camera module Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module: The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion. Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3Â°C (clocked at 240-600 MHz) For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy. Other use cases Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely: OpenELEC HW accelerated video decoding RPi-Monitor I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums. All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot: cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.