PoV

After installing the above python library, simply run this python script :

Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
 
Hi All,
 
I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
 
Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
 
However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
 
Step 1) Adjust /etc/lirc/hardware.conf
 
Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
 
For Ubuntu Xenial (September 2017):
 
The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
# /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
For Debian Jessie (~year 2016):
 
By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
 
Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
# Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
  As lirc is actually already running and installed in Armbian, do the following:
 
root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
 
Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
  user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
    Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
Pressing the remote reveals events like:
Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
 
 
Step 5) Configure lirc to map IR input to key presses or events.
 
Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
 
There's plenty of information on how to use irrecord, command I used was:
/etc/init.d/lirc stop ...to first stop the service, then:
irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
 
 
Step 6) Test with irw
 
Now that I recorded my configuration file with irrecord:
/etc/init.d/lirc start .. to start lird service again
 
then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
  Step 7) Create a /etc/lirc/lircrc file to run commands
 
sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
# http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
 
 
Additional References:
[Guide] Android + InfraRed (IR) + Kodi 
How to setup Remote Control for Linux

I don't have access to my OPi lite right now, but I think there are the commands you should execute:
Create a conf file with encrypted credentials. You should execute the following: wpa_passphrase "ssid" "wirelesskey" > wpa_supplicant.conf Start wpa_supplicant supplying the previously created conf file: sudo wpa_supplicant -D nl80211 -i wlan0 -c wpa_supplicant.conf I think this should be it.

Cool cool. I've just ordered a Plus 2E (and a $12 Plus). I'd still prefer they'd make it 4 USB ports, instead of adding the OTG port. I'm not sure what WiFi adds to cost ($2?), but I wish they could make some tweaks and bump it even more; Either with even more eMMC, or down to $30 instead of $35.

I powered the OPi PC with
passive PoE (supply 6V to PoE injector, extract 4.5V-5.5V at the PoE splitter and feed it to GPIO pins) normal 5V/2A PSU with 1.7/4.1mm barrel plug normal 5V/2A USB PSU together with USB 'Type A to 1.7/4.1mm barrel plug' cable bench PSU to GPIO pins 12V PSU with step-down converter to GPIO pins (this was my test setup to get the valid DC-IN voltage range for headless operation: 4.5V-5.5V on the PC) Regarding UART-to-USB solutions: They backpower the board somehow so you get often in trouble when you try to do a clean restart. This leads to all sorts of weird problems (for example DRAM calibration might go wrong). As a rule of thumb: If strange stuff happens after a reboot think about shutting the board down and disconnect the adapter for a couple of seconds (or look for a working reset switch on the boards -- this was one of the first things linux-sunxi devs did on the Pine64: Solder this button/switch)
 
Regarding the new H3-OLinuXino-NANO I see two potential disadvantages compared to the Orange Pis:
It seems Olimex is now using Micro USB for DC-IN They will use a fixed voltage regulator for the SoC's core voltage so you will be limited by the voltage they choose regarding maximum cpufreq I hope Tsvetan will answer/clarify my last comment here: https://olimex.wordpress.com/2016/02/03/h3-olinuxino-nano-is-only-50x50-mm-but-has-everything-one-computer-must-have/#comment-21665 (I wrote 2W instead of 2A in the hope that this will trigger a reflex)

Nope: http://linux-sunxi.org/Orange_Pi_PC#Tips.2C_Tricks.2C_Caveats
 
In case you're doing development work with such an UART-to-USB adapter you should keep in mind that this adapter somewhat powers the board also and that sometimes you run into strange symptoms trying to reboot the device when the serial connection remains established.

Great news: My Pine64+ dev sample arrived. Due to advanced packaging techniques the position of components could easily be explored without opening the sleeve:
 

 
And here you can see Eular + Ext connector:
 

 
 
Serial console output from first (and also last ) boot attempt: http://pastebin.com/9NfD8FxX

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.

Xunlong did no improvements to any of their images. They released a few ones in the beginning and then community took over. With Xunlong OS images you won't be able to use Ethernet or USB on the Orange Pi PC since definitions were wrong. CPU cores would've been shut down when overheating (and they wouldn't come back until the next reboot). Every improvement made was done by community members and required sometimes massive pushing of Xunlong's Steven to release necessary informations. The SoC used is pretty irrelevant.
 
Regarding software it simply doesn't matter what Xunlong did in the past or will do in the future. And this is the same with Pine64 -- but they never created the impression they would care about Linux or even made any promises! They said just: "We do Android, community does Linux" (and sent out over 50 dev samples in the meantime -- the linux-sunxi devs now doing the fundamentals and members of the Pine64 forum afterwards flooding the net with shitty Linux OS images )
 
EDIT: Just to prevent misunderstandings: The Pine64 folks do care about Linux support (trying to get source code from Allwinner and pushing them a bit in the 'open source' direction) but don't provide it on their own. 

There's some sort of a hard limitation at 25 MB/s (50 MHz data rate at 4 bit). Can be overcome if hardware vendor and drivers provide the ability to switch voltages (default 3.3V, for faster modes is 1.8V needed). I'm not that much into that, you should better read from here on: https://olimex.wordpress.com/2016/01/22/a64-olinuxino-routing-completed-but-we-still-have-to-final-touch-this-and-that/#comment-21480
 
 
 
Not true. Until yesterday they had 2 boards relying on A20 and some based on H3. The A20 boards seem to be discontinued and everything regarding software/support for the remaining H3 and the upcoming H8 based board depends on community. You must be a moron if you think you get decent software/support at the price of $10 or $15.
 
H8 on the announced 'Orange Pi 3' is another variant of A83T used on Banana Pi M3 so I would suspect software support will be as crappy as now with Banana Pi M3 or pcDuino8 Uno (also H8 based) EDIT: (I though about Cubietruck Plus that relies on H8).
 
H64 on the announced 'Orange Pi 3' is another variant of A64 used by Pine64 so regarding software support you either have Allwinner BSP crap or wait for mainline u-boot/kernel done by linux-sunxi community. I wouldn't expect that Xunlong has resources/knowledge to provide a good OS image. The best they can do to release soon is to take any of the crappy Pine64 images based on Allwinner's 3.10.65 kernel provided by the Pine64 community and to exchange boot0/SPL to be able to boot H64 instead of A64. It will be as bad as it was when Xunlong started with H3
 
But regarding H3 everything interesting will happen at linux-sunxi and not Xunlong.